I am only now again looking into the HourGlass 1.5.x code.
If things go well, an initial beta release will happen during this month. For Windows I will probably need to require the users to install the C++ runtimes separately. A big and long sigh, but what can I do. That crappy way of doing it is what Microsoft wants. 😦
Some progress (click image for bigger animation) :
–
Finally did some work on HourGlass so as to not forget about it all.
The multichannel stuff for the VST plugins is just about getting actual multichannel plugins to run more properly. I bumped into crash issues trying to use the GRM Tools Spaces plugin, which has 32 inputs and 32 outputs. Well…Of course the HourGlass code has had just 8 channels worth of buffers allocated for VST plugins for many years. (Even before doing work on the multichannel stuff, I bumped into some plugin that wanted 8 I/O channels by default, so I provided that many back then already…)
It’s another matter making mono or stereo only plugins run as pseudo multichannel. I will try to make that happen at some point…
The latest commit for OS-X is a nice bonus. I wanted to myself see the ini files for HourGlass on OS-X and it was quite a hunt! The default location the Qt framework gives for them is quite irritating. So I finally made the ini files be located in /UserName/Library/Application Support/Xenakios. Should be somewhat easier to get access to them now!
I’ve been busy making a new composition during August (based on water sounds…) and haven’t done any work on the HourGlass code. I will be busy with the composition during September too, so a release of HourGlass 1.5 even as a beta isn’t likely soon.
The Microsoft runtime library issue still seems unclear. There isn’t an official update on the issue but some comments in the Microsoft C++ compiler blog indicate it might now be possible to deploy applications with the needed libraries with the application itself without the need to install the libraries first. This isn’t a HUGE issue but it sure is annoying me a lot on principle. Especially considering there have been reports the separate library install may also require a reboot of the computer. I would completely hate having to install something like that myself when trying/updating a software. There is still the possibility to go back to VS2013 too, but I’d rather not, since VS2015 has the newer C++ compiler and standard library. (For the technically inclined : static linking of the C++ runtime is problematic because HourGlass uses the Qt library which has had mentions in the past that static linking isn’t really supported. There may also be licensing implications mixing LGPL licensed code with Microsoft’s code.)
I’ve also started thinking there should probably be more comprehensive support for multichannel operation in HourGlass. The code still has some limitations on the number of channels supported and the fragment spatialization still can only pan to 4 channels. I’ve done some experimenting with a 5th loudspeaker in my set up and have started to like that so much that I’d like HourGlass to be able to do something with it (and more channels in the future) too.
Also I’ve realized there are hardly any 3rd party plugins that support multichannel operation, so having some solution in HourGlass to use those plugins at least in “pseudo multichannel” mode seems essential now…Technically that should be pretty simple to implement but I just haven’t got to that yet. (I feel a bit ashamed about this, since even damn Pro Tools implemented that in the first version that supported multichannel operation back in 2001 or so! On the other hand, Reaper still doesn’t have a convenient solution for it…)
I was almost ready to post a build but bumped to a Microsoft caused issue a few days ago. The latest build on Windows has been done with Visual Studio 2015 which has added an annoying problem of how the software built with it it supposed to be deployed to other computers. It would basically be going back to how things were with Visual Studio 2008 and how I had to tell people to install the Visual Studio runtimes before trying to run HourGlass. Isn’t it great how progress progresses from 2008 to 2015? Oh wait…
I am going to see a for a while if Microsoft will again make it possible to distribute the Visual Studio runtime DLLs directly in the application’s own directory. If they won’t make that possible, I will have to revert back to Visual Studio 2013.
Oh and as a sidenote to Windows XP users…Sorry, that age is now over. HourGlass 1.5.0 won’t run on Windows XP, no matter if it is built with Visual Studio 2013 or 2015. Microsoft says it’s still possible to build for Windows XP with the newer Visual Studios, but I’ve never got that actually to work and I am not really interested anymore in spending time and effort on that. I certainly don’t love Microsoft and everything new they do (as evidenced by the above displeasure with VS2015 and I doubt I’ll be getting Windows 10 either), but sticking with Windows XP just doesn’t seem reasonable to me anymore.
OK, time flies by so fast…I haven’t extensively worked on the next HourGlass release lately, but it will appear at some point. I’ve been distracted remixing an old composition of mine from 1998 into quad. And there’s been no need to use HourGlass or its new multichannel capabilities for that.
I suppose I could put out an alpha release in the coming days. I know there are still bugs that are related to the multichannel stuff, but the alpha would at least give a taste of the new HourGlass version. And maybe some bugs that are not already obvious to me could be discovered by other people than me. Also I could consider some feature suggestions.
Finally did some tests with per-fragment panning!
At the moment I am not entirely sure how effective this is sound-wise. The panning movements within the individual fragments can get easily lost when many voices are playing at once or when the fragments are short etc…My initial hunch that the static pan positions per fragment are enough for HourGlass might be right.
The additional CPU load might not be too much though and the per-fragment panning can also be turned off. For now this is just doing a simple linear interpolation (straight line) between 2 pan coordinates. Allowing more complicated paths might be more interesting sonically, or not…
Making a suitable GUI for this may be quite involved. The solution which seems obvious at first, just letting the user draw a pan path is not really enough. Each fragment should be able to have its own panning path. But the user can’t really be expected to draw hundreds of paths etc…Now, there are solutions to this like the user drawing a few paths which are then assigned to the voices in a round robin fashion or randomly etc. But I need to think this further before making anything too complicated since it’s not entirely clear if the per-fragment panning paths even sound that interesting at the moment.
