The thing is that in OS-X Lion(*) the developer tools are set to build 64 bit binaries by default. Also, the biggest 3rd party library Qt
I am using in HourGlass is only available as a ready-built binary in a 64 bit version. I have built a 32 bit Qt now myself, but I have not really yet tried building HourGlass
against that. I am hoping that I also get the additional libraries (mainly libsndfile and PortAudio) to build as 32 bit. Then it should all work.
Why is 32 bit so important? Firstly, I think starting to implement the VST plugins hosting wouldn’t be of much use otherwise…VST plugins are a bit odd-ball on OS-X anyway (Apple’s preferred
choice being that hosts should implement AudioUnits), so I don’t suppose that many 64 bit VST plugins exist on OS-X.
Secondly, my guess is that the chances are better for older OS-X versions
to accept HourGlass as a 32 bit binary. But as I noted in an earlier blog post, I am not going to enter into a fool’s quest trying to make HourGlass run on OS-X 10.5 or even 10.6. Apple just doesn’t make compatibility easy! It would be a bit different for me as a developer if I was doing a commercial product I would sell. Then obviously additional work to allow running in earlier OS versions would make business sense. As it is, any extra work needed for that is just extra work that I get no personal benefit or enjoyment from. If you as a user really do love Apple, then you would have updated or will update soon to Lion anyway. And OS-X 10.8 will be soon out too…I am not volunteering to do extra work just because people want to be stuck on OS-X 10.5/10.6, and I don’t think I am even that sorry about it. Note however that this is simply the pessimistic view of the issue. It is possible HourGlass might run on at least OS-X 10.6, it just hasn’t been tested yet.
However, because the VST plugins hosting code doesn’t exist on OS-X in any case at the moment, I might just as well first try releasing the 64 bit version of HourGlass for some
brave souls to try out. (Maybe during the following week.)
(*) Why I am using Lion anyway? To be bleeding edge, I suppose. 🙂 And also to be able to run an up to date XCode and the related toolchain. Which also allows developing applications for iOs…(But that’s something very speculative at the moment.)