Development of Bounce Metronome for mobile devices, Mac, Linux etc.
From Bounce Metronome
Summary - Currently for Windows only
Bounce Metronome is designed for Windows XP, Win 2K, Vista and Windows 7. It is no longer compatible for earlier versions of Windows. The last Win 98 compatible version is 18th May 2009 (a lot has happened since then). Also not compatible with the Windows CE you get on some mobile devices and very small netbooks.
Sorry, no native version for Mac, Linux or mobile devices. I do have plans to make a stripped down version for mobile devices, a much simpler app, a different app for each type of rhythm.
If that's of interest [contact.htm contact me ]and say what type of device (e.g. Mac, Linux, Android, Palm, iPad, Blackberry or whatever) you want to use it on and I'll add you to the list to be notified if / when I have a version for your platform.
You may be able to run it on a Mac using VMWare Fusion, possibly also with Parallels Desktop.
Future plans for mobile devices
It's not available for mobile devices yet. However, I'm going to see if I can do a stripped down version for these at some point hopefully this year - see also discussion and poll at thegearpage.net
For a Mac.
With a Mac. your best bet probably is to try it under VMWare Fusion or Parallel Desktop.
Or dual boot and install it under Windows in your Windows partiton on the Mac.
It's been used successfully under VMWare Fuson, under XP (which may be better than Windows 7 especially if the memory available for the Virtual Machine is low).
This is probably your best solution for a MAC.
This is probably your best long term solution. Realistically I won't be able to port it fully to a Mac because that involves rewriting it all pretty much from scratch and requires someone with experience of coding for a Mac.
The version for mobile devices when ready (if that works out) may work on a Mac depending how it is done - I will try to make it Mac compatible if I can.
If so, it will be a much smaller program with fewer features and rhythms (probably as a separate program for each of the main types of rhythm). Though hopefully still pretty useful :).
It can't run on Windows CE so if you want to run it on a smartphone or mobile device, you need one with Windows XP. I don't know of any for sale now but there is at least one such device in development (the XP Phone) though rather larger than most mobile phones - so it's something we may see more of in the future.
The smallest device it can run on at present is a netbook PC or net tablet PC with Windows XP.
If the screen is very small, then you may need to use Bounce Metronome Pro's option to split the main window, which you access via "SPLIT MAIN WINDOW" in the options drop menu.Â You can then run it on 800 by 600 pixel displays or even smaller. If your screen is very small, too small even for this, contact the developer, as I may be able to develop a version for smaller devices.
For more see the wish: Make it possible for Bounce Metronome Pro to run on a mobile device
However, now considering other approaches such as flash or WebGL (in future)
Export Videos for other devices
It can't run on an iPhone or Blackberry, and there are no plans to port it to those devices. However if you have a Windows machine as well, you can use it to export videos (with sound) to run on other devices.
No support for native Mac or Linux application
There are no plans to port it to the Mac or Linux. #More about why it is so difficult to port Bounce Metronome Pro to a Mac or Mobile Devices
However there are ways to run Windows Apps directly on a Mac on your desktop alongside your other programs, which may be worth a try (they come with free trials and some solutions are free).
For (most of) these solutions you will need a copy of Windows. Any version of Vista, Windows 7 or XP is fine as the OS.
Your options at present are:
- Get yourself a cheap Windows PC just for the metronome.
- Run Bounce Metronome Pro on your Windows partition on your Mac using Boot Camp (if you use XP must be SP2 or later).
Other options - don't know if these work:
- Run Bounce Metronome Pro alongside your Mac programs using a "virtual machine" such as VMWare Fusion, Parallels Desktop, the free Virtual Box, or (for older non Intel macs) Virtual PC. See #Virtual Machines for Mac
- Run it using Wine for Mac or Crossover - this option doesn't require you to buy Windows but may be techy. See #Wine for Mac
- There are also some other approaches not used that much. Here is a good overview of the different methods for virtualization on the Mac.
I can't offer support for installing my programs on a Mac or any issues that may arise.
I don't know if any of these solutions work but they are well worth a try if you are up to it.
Some time I'll try it myself when I have a Mac machine to try them out on (or if I can borrow one from someone) and then will update this with my findings.
If you have tried out the virtual machine or crossover solutions yourself, do let me know - even if it was only a partial solution or you encountered issues - that's also useful and I'll update this accordingly - or you can post about it yourself to the Bounce Metronome Pro Forum.
Why I can't provide a Mac or Linux version
The thing is that it is written specifically for Windows at a low level. There are alternative approaches that let you code a program that will work on Windows, Mac and Linux from a single code base, but it has to be done when you plan the original architecture.
The only way I know of to do it now is to write most of the program again from scratch, either for a Mac in native code, or multi-platform. Apart from that - well it uses a completely different architecture so you can't expect it to run on a Mac "as is", and there is no way I can modify it to do that.
To find out more see #More about why it is so difficult to port Bounce Metronome Pro to a Mac.
I'll focus on Mac here because many pro musicians use Macs and it is the OS that I get e-mails about. If you use Linux skip to Wine and Virtual Machines for Linux.
Wine for Mac
This is a relatively new development, although Wine for Linux has been around for a long time. Wine for Mac only became possible with the new Intel Mac machines. It doesn't require you to own a copy of Windows as the code is rewritten from scratch to function in the same way as Windows, and doesn't use the Windows dlls at all so doesn't need a license from Microsoft.
Basically, the approach of Wine is to write new versions of all the Windows routines for the Mac - then the software when it calls these routines can use them in exactly the same way it does on a Windows PC.
To find out more see this Wine for Mac tutorial. I don't know if Bounce Metronome Pro will work.
There's a commercial version of Wine for Mac as well called Crossover.
It's quite likely it will as it only uses standard Windows routines, however you never know for sure until you try. Sometimes the Wine emulation isn't quite perfect so that the routines don't work in quite exactly the same way they do on Windows (when this happens it is a bug in Wine as it is intended to be a perfect emulation) - and Bounce Metronome's Armadillo Shell (written by a third party) may cause issues with Wine.
I can't help in any way with installing it on a Mac or with any Mac related issues that may arise if you do this.
If you can get it to work please let me know. I will be delighted to know if it does work and it may help other Mac users.
If there are any bugs relating to the program itself, then I will do what I can to help you to resolve them.
Virtual Machines for Mac
You may be able to run the program on a Mac alongside your other programs, if you use a virtual machine. (all the links in this page open in new windows). The approach here is to do a virtual version of the processor itself - then you run Windows on that virtual machine.
So that's why it requires you to own a copy of Windows as it only virtualises the machine, not the operating system. Virtualising the processor itself sounds like quite a slow thing to do - and it used to be - but on a modern virtual machine then through clever coding they are able to get the virtual processor to run just a few percent slower than the hardware processor on your machine. A lot of the Windows code may be run "as is" directly on your hardware processor itself - with only minor "on the fly" changes to it.
You should be moderately techy to try this approach, as I can provide no support for installing the virtual machine on your Mac or any issues that may arise on your Mac when you do it. Some find this easy and some encounter problems - see these comments at amazon.co.uk for the 2009 version of Parallels Desktop for examples (though they have moved on to a new version since then)
For a Mac, you can try VMWare Fusion, Parallels Desktop, the free Virtual Box, or (for older non Intel macs) Virtual PC. All these solutions require you to own a copy of one of the Windows operating systems, however they let you run Mac and Windows programs at the same time on the same desktop in a seamless way. For the OS then Windows XP should be fine. The virtual machines are reasonably low cost (free for Virtual Box), so your main cost is likely to be the price of the Windows OS.
Here is a techy comparision of VMWare Fusion with Parallels Desktop at wikipedia.
For other virtual machines - in case any tehcy readers of this page want to try out the less used alternative approaches, see virtual machine (wikipedia).
Be sure to let me know if you get it to work - especially as this could be of interest to other users. I get asked about this quite often, and would be delighted to hear about it if anyone finds a way to get it to work on a Mac.
If any bugs occur and you provide bug reports then I can look into it. I may be able to help by remote diagnostics and logs.
The programs themselves use only documented Windows routines, so would be expected to work on a fully implemented virtual machine, but the system I use to protect the software from crackers, which is designed for Windows and is a third party proprietary product - might cause issues on some virtual machines particularly combined with virus scanners.
Nowadays this approach is reported to be very fast near native speed. Typically benchmarks show that the virtual machine slows the operating system down by just a few percent.
Virtual Machines for Linux
You may be able to run them on Linux using Wine, or again (as with the Mac above), a virtual machine. The Wine approach is completely free, developed independently from Microsoft, see the wikipedia article Wine for details.
Again as my programs only use documented Windows routines they may perhaps work with Wine but again the software protection system might cause some problems. I know that Activity Timer has been used on Wine so it's possible to run some of my programs in this OS anyway.
Ideas for porting Bounce Metronome Pro to Mac, Android, Linux or Mobile Devices
There are several approaches to try - none of them really pan out at present but maybe some will in the future. The best solution is to do a lightweight not so feature rich version. To port the complete program seems impractical at present. Perhaps the best solution is a multi-platform 3D games engine such as Unity
See also these two discussions on thegearpage.net : Which Features interest you most for Mobiile devices or Mac? and Amazing Software Metronome
The lightweigh version would be an App suitable for phones, much reduced capabilities compared with BM Pro but still with the features that are of most interest to users such as polyrhythms, mixed meters, and (if possible, depending on 3D capabilities) the gravity bounce. There would be a different app for each main feature or type of rhythm.
Depending on the development tools you use to make it, it may be able to run on a Mac, Android and Linux too, as well as many phones. This is possible if it uses Html5, Flash, Java or (perhaps) Silverlight as a basis or some other approach of that nature - basically stand alone apps based on browser plug ins seem a good way to do a lightweight multi-platform app which may work on many phones as well.
Another possibility is to use a multi-platform game engine such as Unity, which you code with once and can then deploy as separate apps for many different operating systems.
One issue here is that these approaches may not support midi. I mean - very probably would support playing a midi file but not playing individual midi notes in real time at the exact moment you want to play it.
Also they might not interface closely with the audio on your computer so there might be latency or other audio issues, depending on the technology used. Latency isn't an issue with a metronome so long as it is fixed and you know the amount of the latency, you can just delay the visuals accordingly. But the audio timing of course has to be millisecond precise.
It is surely months of work even to do that properly - and I have many other things to do, so don't plan to do this right away. Meanwhile mobile devices will get better and ways of writing multi-platform code are likely to improve so I will revisit this later on.
Details - read on.
Porting to native mac code
This page about how to port a Windows 32 app. to the Mac gives some idea of how much needs to be changed to go from one environment to the other.
That page is techy, so unless you are developer yourself, won't mean much. But basically nearly everything I have learnt to do on windows for things such as mouse and keyboard processing, working with windows, drawing graphics, setting colours, setting styles of brush and pen, etc, has to be done differently on a Mac. So I would have to learn it all again from scratch - a little like learning to write in Japanese perhaps :-).
While learning to do all that I'd have to put most of my other programming work and Windows development of the software on hold and it would take surely at least some months before I have my first prototype version of a metronome for a Mac, and probably much longer to create anything as complex as BM Pro.
So, I'm not likely to do that in the near future.
Techy details - why it is so hard to just port the existing code to Mac or multi-platform
The code calls Windows dlls all the way through - if you take a random sample of the code for Bounce Metronome or Tune Smithy, there is a good chance that it has at least one or two calls of window routines. It is designed around the way those windows routines work too, even simple things like drawing a line or polygon can be done in different ways in different OSs and other things like midi, audio devices etc would be expected to be very different - not just a matter of changing the routines you call to new routine names.
The code is also called by Windows as well, in a complex fashion, indeed in Windows then if you look at the list of functions on the "stack" you always have Windows at the top of the stack. So Windows drives everything, I've seen it described that in Windows all programs are "extensions of the operating system".
For instance every time a control refreshes, it does that in response to a call from Windows which calls my program to ask it to repaint the control.
Then, every time the user clicks a button or presses a key, Windows handles that first, and then calls my code after it has done processing the user input. My code then may call windows back again at that point, and Windows then may call my code back once more - so depending on the situation, that interaction can go back and forth several times before your click key press is finally processed completely.
All the 2D and some of the 3D graphics drawing is also done through windows routines, and Windows also handles most of the presentation of the windows, the buttons and other controls - most of that is done within Windows and you never see it. You just get notification that the user pressed a button or adjusted a slider etc. So, except for skinning, my program doesn't handle the way the controls work either, so none of that code is portable to any OS either.
So basically it is
Porting to multi-platform code
To write it multi-platform would be similarly complex - at least with the multi-platform tools I know of. They tend to be higher level than native code for another OS, so it may be a bit simpler than the native code, but not that much simpler. You still have to learn how it works, and learn new ways to do all those things such as mouse and keyboard handling, window management, graphics work etc.
The main advantage of this approach is that it lets you maintain a single code base if you decided originally to write for both Windows and Mac. If I did that originally then it would be multi-platform - but back then when I started on Tune Smithy in the 1990s, programming multi-platform like this was rare, and the results were mixed in quality.
This approach loses much of its advantage when you have written the code for Windows already.
By going mult-platform then you are no longer working so closely with the operating system. So the software may be slower, or more importantly, the user interface may not be quite exactly the way users expect it. E.g. maybe the File Open and Save As dialogs may have an unusual layout, not as expected for the OS, or just small details may be different in ways that may confuse some users.
Disadvantages of a multi-platform app
A multi-platform app often is less easy to use than one designed for the target OS as users have different expectations etc. Here is aforum post by someone who did a multi-platform app which he then had to port to native Windows to give a better user experience. As he says also in that post "A Windows developer is likely not the best choice to create a 'good' Mac application and vice versa." and there is more to learning to develop for a platform than just learning how to write code for it.
Nevertheless, as a single developer not able to employ a team of people to work on versions for different OSs, then this might well be the best way to go.
Writing for scratch using new super-efficient coding languages with multi-platform support
Most modern coding languages are still pretty complex to use for the sort of work I do, and either require many lines of code - or if they use few, then require a lot of thought about how to write those few lines. Same applies to the multi-platform code.
There is one very interesting looking new language called Ultimate which offers an extraordinarily simple (few lines of code) way to write applications for Windows, and looks as if it could be a way to get started writing the code from scratch in less time than with most environments. It has OpenGL support so could be expected to do the 3D graphics. So - if it ever got ported to the Mac it could be a bit simpler perhaps - I don't know. Bit of an academic question as it doesn't yet have Mac support, but they have discussed it - seems it is something that could be done and just requires a programmer to get involved in it with an intimate knowledge of both Mac programming and Ultimate . If they ever do this, and if it works, it could be an interesting approach, and similar enough to C to be easy for me to learn.
Another one is RealBasic This is a mature multi-platform language, compiles your apps to Windows, Mac or Linux, develop on any of the three platforms, and with drag and drop user interface development. Looks promising.
Best way to do a Mac port is to get an experienced Mac developer to do it
To do a Mac port, if I try to do the native code approach, then in many ways the best approach would be to employ a Mac programmer to do it for me. But that would be expected to cost tens of thousands of dollars, or indeed at commercial rates, more like hundreds of thousands of dollars to produce something like Bm Pro in all its detail. That's not yet a practical thing for me to consider.
Also, they would have to be an experienced programmer to do something like this, ideally also with a fair amount of experience of music software development - able to handle Midi, 3D graphics, multiple threads, thread synchronisation (to keep the 3D visuals and the music in time), and much more that's just the tip of the iceberg. They would also need to have a good understanding of mathematical concepts (including vectors, matrices, trigonometry, etc.) and of musical concepts as well.
Or find a keen Mac programmer collaborater with experience of developing complex musical apps (preferrably with 3D graphics experience) - but then such a person chances are already have their own programs for the Mac. Like - for instance Jeff Scott - I'm sure he could do it, but has his own programs which deservedly take up all his programming time, such as his L'ill Miss Scale Oven for the Mac. so I wouldn't even think of asking him if he wants to do it.
For that matter unless the Mac version gets as advanced and feature rich as the Windows version - it might have quite a short lifetime.
Because, I think virtualization technology is going to continue to improve, has already improved remarkably in just the last two or three years. Soon it will probably be as easy to run a Windows program on a Mac as it is on Windows, maybe even with Crossover or the like not even requiring purchase of the Windows OS. By the time you've spent a year or two developing a Mac version you might only have a year or two to sell it before everyone is running the Windows version on Macs unless it is noticeably better for a Mac than the Windows version.
(This was written a while back - virtualization still doesn't seem to have achieved the promise that was expected, nowhere near the situation yet where anything written for any platform can run on any device).
Idea, lightweight multi-platform taster
One other idea is to do a rather lighter version for a phone, using some multi-platform approach that can run on phones, Macs, Android and Windows. Ideally maybe in a web page too. So then you get a taster version type lightweight Mac program as a byproduct which still may be useful enough for many musicians to want it - and also get a version for phones as well, which makes it worthwhile developing a lighter weight version.
The main Bounce Program for Windows would still be the "best" and most versatile version. But the multi-platform one could also be made innovative and explore new ideas too.
One approach - using web browser technology and target mobile devices as well
There again you are probably thinking of using something like Java, Flash or Silverlight or some such to develop it - the sort of languages you use for browser plugins which can also nowadays also make stand alone applications.
The thing is - by targetting phones, then you don't need to think about trying to make something similar in capabilities to BM Pro, something more modest would be fine.
It could still be useful and innovative with the gravity bounce if you can do it, and it mightn't be that hard to add polyrhythms and mixed meters once you got that far. But anyway no immediate plans to explore this, too much else to do right now and not sure if it can be done or not.
One issue here is that these approaches may not support midi. I mean - very probably would support playing a midi file but not playing individual midi notes in real time at the exact moment you want to play it. You also want to be able to use controllers such as pan (ideally) and certainly want to be able to send midi messages to change the midi instrument etc. If you have access to the low level application interface of the OS then you could hope to write custom code to do that. But plugins are usually insulated from that in a sandbox for security reasons.
So - anyway - that just means one needs to research carefully before you start on it, to make sure you can do what you want. And maybe one approach is to just not support midi, do it all using mp3s for the instruments - not too bad if you focus on the non melodic features. Could even do the harmonic metronomes maybe if there is some way of pitch shifting a simple mp3 sample (e.g. triangle wave or whatever).
Another advantage of doing a web page type app is you could do a simpler stripped down version for free and embed it in a web page so very easy for anyone to access. The free on-line metronomes are popular and useful, also they go up high in the search results too, so good advertising :-).
So anyway - possible ways of doing web page plug in type multi-platform apps:
A first quick search right now suggests of the three methods mentioned, probably Java is the most likely to support the midi side of things - the others may catch up (not that many years ago you couldn't do any midi in Java at all) but Java seems to be most mature as far as cross platform Midi support is concerned.
There's also a pretty good looking add on for Java, jsynthlib which looks as if it would help a lot with midi work:
But Java often has issues on the Mac. which is a drawback.
Here is a page with lots of 2D bouncing balls - do they bounce reasonably smoothly on a Mac? I mean - just whether the animation freezes at all or seems continuous.
As for appearance I can make them look nicer and 3D and easier to follow
Here for instance, orbiting planets
Don't worry if it seems quite basic. Once I have a working demo, I can surely gradually add texture mapping, shadows, splash effects etc. as in BM Pro.
The other element is sound. With flash, could just embed the sound as mp3s to start with:
The big disadvantage of Flash at present is that it isn't supported on iPhone or iPad. Steve Jobs says the reason he doesn't want to support it is because it crashes on the Mac, is slow, and uses lots of CPU power so would reduce battery life. Though speculations that it may also be to do with keeping the iPad locked to apps in the app store. Speculation about Steve Job's decision abounds on the internet, Jobs Says Flash Crashes Macs No Flash for iPad iPhone Planned/article17738.htm example here.
I can understand his points about battery life, and running slowly. But can't say I'm won over by many of the rest of his arguments myself. If the techy issues can be solved, then those are the main points of his letter that bear weight, fo rme.
Some of his reasons for not supporting Flash are the very reasons that I am interestsed in using it - because it is cross platform. I'm not sure why that is a drawback - if you want to exploit all the native capabilities of a platform you do a native app, while if you want to make something cross platform, generally you want it to work in the same way, as much as possible, on all platforms.
So I don't see why Flash's multi-platform capabilities are a reason for not supporting it. Would be a good reason for not relying on it as your only way of developing apps for the hardware of course, but as a reason for not supporting it at all - I don't understand that.
Anyway will see how this develops.
As for the techy reasons for Flash running so slowly on the iPad, I wonder if in the future that may get solved.
That article isn't about the iPad as such - but wonder if perhaps if they can overcome whatever the issues are that make flash slow, as they seem to have done there with at least some graphics cards - then Steve Jobs may change his point of view.
There is no competition for the iPad at all right now. But there are lots of iPad competitors on their way in a few months time. 32 different devices at a recent count though that includes a few that are just a concept and not yet even prototypes. But a good few that are potentially serious rivals in a few months time:
And despite the hype about html 5, doesn't seem likely that it will replace Flash in the near future at least:
Seems possible and worth exploring further
Googles O3D is impressive, but deprecated and no sound integrated into the engine. It's getting moved to WebGL which is pretty much in beta at present but will probably be shipped to all the major browsers towards the end of this year.
Big plus is that Apple is fully behind this approach.
Some samples of O3D here
WebGL looks very interesting for the future, will see how it develops later this year.
The great thing is, it is very similar to OpenGL which I am familiar with as the 3D scene in Bounce Metronome Pro is done using OpenGL.
Also found a (paid for) program CopperCube that can output either Flash or WebGL, maybe there are other programs that can do the same?
RealBasic - again promising.
Unfortunately not supported for the iPhone or iPad again.
Making an audio plug in
For Mac, if you had a mac programmer you could look into an audio unit. Or if you had a programmer experienced with writing VST plugins, you could do a VST with a wrapper to make it compatible for a Mac, better for multi-platform code, if I understand correctly.
This isn't my field of expertise, either Mac programming or writing plugins - and I think it would take me a fair while to get up to speed with it.
3D Games Engines such as Unity
Another idea is to use a 3D games engine as some of those are cross platform.
A search for platform 3D games "cross platform 3D games" turns up quite a few likely looking candidates.
This is a good looking one: the Irrlicht Engine - mult-platform support including Mac, iPhone etc. Main thing is how well it handles midi probably.
Another one that looks very promising is Unity
It would depend on how well they support midi, or if there is some 3rd party plugin you can use to add sufficent midi support for the metronome features. But if this approach panned out, it might be the quickest way to do it and also give high quality visuals in 3D as well.
Just a few ideas at present - which I may return to at some point in the future as technology and software gets better, or if I have lots of time for some reason, or earn enough to employ someone else to do it.