And surprise, surprise, it’s bad news, of course. I will probably need to discontinue HourGlass, so if you are interested in it or have lost the download, you should get it now.

The reason for this is the Steinberg VST2 licensing situation. They are now determined to stop as many developers as possible from developing and distributing anything VST2 related. HourGlass hosts VST2 plugins, so it is under the Steinberg licensing terms. It looks like I was too late sending in my license application for them and it is not going to be accepted. I will wait for a while still, but if I don’t get a positive reply from them, I no doubt have to remove the HourGlass download links.

There is a chance I might look into making a new build of HourGlass that has the VST2 hosting removed. It’s not as simple as removing/disabling some code, however. Because 4 years have gone by since the last build, much has changed in the development frameworks and tools. I would for example need to update the code to use the Qt5 framework(*). I may not find it worth it going through all that trouble, especially if it was only to produce a version of the software that will just have a feature (the VST2 hosting) removed from it. But let’s see…

The situation also means I may have to discontinue the VST2 version of the PaulXStretch plugin soon. Also, if/when I get back to working on λ and if public builds of it appear, it will not be able to host and use VST2 plugins.

So, thanks a lot Steinberg! You sure seem to love VST3 very much and expect everyone else does too.

(*) Migrating to Qt5 wouldn’t really strictly be required, but it would be insane to use Qt4 anymore. Using Qt5 might even make the HourGlass GUI look and feel a bit nicer on macOs…

OK, so things have been rather quiet here in the blog. No news about λ and so on. I have been working on lots of different things, none of which have gotten to a state I would have liked to release to the public. This changed a bit some time ago when I decided it’s time to update the venerable Paul’s Extreme Time Stretch application.

I took out the old FLTK-based GUI code, the PortAudio code and the code that it used to use for reading and writing audio files and replaced all that with JUCE-based code. As I should have expected, it all turned out to be a pretty big project. But anyway, I finally managed to do something that I felt was worth releasing to the public for testing.

edit 23rd December 2016 : λ is not yet available for download, and no date yet…(It is still in a development stage where I’d have to release new binaries every day in order to deliver bug fixes and I have no streamlined solution for doing that…)

Since early 2015 I’ve been working every now and then on an application, now named λ, that was originally intended to be a modular GUI front-end for the Composer’s Desktop Project (CDP) command line programs. During the past few months I’ve started developing it more actively and it is becoming something larger. In addition to running the CDP programs, it now also hosts VST2/VST3/AU plugins and has some built-in processings too, among them a multilane sound sequencer/mixer. (I don’t want to call it “multitrack” because I don’t want to get stuck with some traditional notions about a DAW application…)

It resembles a modular patching environment like Max/MSP in that it has processing “nodes” or “objects” that can be connected together into a “patch” or a “graph”. However what makes λ a bit different is that each node always has some defined duration of audio or other data available and the nodes downstream can always randomly access all that data. So things like reverse playback or granular processing that “scans” the source audio in any direction/speed are possible no matter what the upstream nodes are doing. (For example the output of a reverb plugin can be reversed and so on.)

Why the weird name that is just the Greek lower case letter λ? Well, why not? 😉 However, if people don’t want to type that character, I am willing to tolerate them using “Lambda” or “lambda” instead. And if the name really becomes some kind of a problem, I may reconsider changing it.

Here are some YouTube videos demonstrating a bit what it can do :

At the moment λ is heavily based on offline processing the nodes into files on disk. However more responsive pseudo realtime processing can be added to some of the node types in the future. It will still however be mostly geared towards composers/sound designers who don’t necessarily need full realtime response, MIDI inputs, audio recording with monitoring etc. λ is not going to become a traditional DAW or even a traditional modular patching environment. There are plenty of those around already, so I don’t need to make one that tries to replicate ProTools, Reaper, Cubase, Max/MSP, Bidule and so on.

And then the question…Is HourGlass dead? It is. 😦 But wait… Not really. It will live on inside λ as a processing node. Currently the HourGlass node is not as comprehensive as the old Qt based application, but it will (re)develop as time goes on.

This month I’ve worked a bit on HourGlass 1.5. So there is still hope a public release will eventually happen. The multichannel/surround stuff sure has been a big mess to implement, with bugs and CPU performance problems popping up at every turn. However, with some private testing generously done byJean-Marc Duchenne with his extreme multichannel audio system (with dozens of channels and loudspeakers), some of the problems have been at least partially fixed.

The longer term plans definitely involve rewriting HourGlass from scratch, based on JUCE. Using the rather ancient Qt4 toolkit is beginning to feel quite miserable, but I will grudgingly persist in getting a few versions of HourGlass 1.5.x done with it for now.

I again did some testing with how to allow entering panning paths graphically…Curves can be added to the path and the path then “scanned” with the usual HourGlass envelope. (Click the image to get a larger animation.)

While this is neat, it does currently have the downside that the added curves can’t be edited later. I need to look into some solutions for that…

Qt has a nice class named QPainterPath that made this easy so far. Various shapes can be added to path and the path can later be evaluated according to a percentage value. This in turn allows creating look up tables that the audio code can use to obtain the panning positions. Hopefully Juce has something similar for the future…(And yes, this similar system could be used to implement the fragment internal panning too, but I will still have to see if it’s worth it doing that.)