Many people have asked about an update to the post from June 2018. I’m sorry things have been so quiet here regarding development, but be assured that plenty has been going on, at least from a programming perspective.
Development was definitely impacted by Paul’s move to near Santa Fe, New Mexico, but now that is largely done and settling in there is well underway, he is now back in action. Here’s a photo of the current state of the new Ardour HQ, in Galisteo, NM (soon to be radically different due to a new self-built desk/console).
Robin, as usual, has been insanely active working on an almost countless series of features and bug fixes. This summer, he redesigned our processing code to use lock-free queues, an important improvement for our realtime code. In the recent past, he added progress notification for Lua scripts execution and introduced support for new LV2 extensions (backgroundColor, foregroundColor, and scaleFactor) that allow a host to inform plugins on host color theme and UI scale factor to play better with non-default themes and on HiDPI displays. Most recently, Robin has also been nerd-sniped into a very full virtual MIDI keyboard implementation that can be used to deliver complex MIDI to any part of Ardour (it shows up as a port just like a hardware device would, and you can connect it just like a hardware device).
Harrison Consoles sponsored the development of a new plugin manager that provides easy access to favorite plugins and favorite presets. They also collected many more MIDNAM files (used to describe various MIDI equipment and their programs) and tagged hundreds of plugins with semantic information. Ben Loftis at Harrison also made some useful changes to the information presented in the Source list (with more planned for the future).
Since the last update, there have been several significant development branches undertaken. The first two don’t have much impact for users in terms of visible functionality, but make ongoing development easier. The first added a formal design known as a “Finite State Machine” to help manage transport state. Before this, it was more or less impossible to explain or logically reason about the state of the transport (start, stop, locate etc.) We now have a much cleaner implementation here that allows us to think more clearly about how this all works (and it is a lot more complex than you would imagine!).
The second development branch to be worked on was a similar “logic cleanup” of the entire startup process. This too was a huge mess at the code level before, and it was extremely hard to reason about where things happened and why. If you wanted to change them, even in a small way, it was a very daunting task. Even fixing a bug such as “why doesn’t the window close button work with this dialog?” was a deep headscratcher. Although the startup process should be identical to the way it has been for 4.x and 5.x, internally it’s now much cleaner and more understandable, again making future changes easier.
Another branch changed the way that Ardour handles timecode (MTC, LTC etc). This is now done by dedicated objects that run all the time during the life of the program (they can be disabled, of course). This means that you can see the current time data being delivered by an MTC or LTC source at all times, regardless of whether you are actually using it. There’s a much more powerful GUI for presenting this data and choosing (and naming) timecode sources. You can also have multiple timecode sources of the same type - not particular useful for a typical home studio setup, but if you’re working with lots of video gear, quite handy.
Finally, the most recent development has been to completely change how we handle managing MIDI data for playback. We have eventually concluded that although theoretically MIDI data could be as large as audio data, in practice it is never even close in size. Since MIDI was first added, we have used the same design as for audio to move data from disk into a track or bus and then on out of the program (when appropriate). This has turned out to be overly complex and unnecessary. We do still have a data structure model for MIDI that is designed specifically for editing. But for playback, we now “render” a MIDI track into a very simple form whenever it is changed, and use this in-memory representation directly. Although it was not the original intent, this should help various MIDI related issues, because the entire playlist for the track is rendered at once, using a single starting point (zero). We are hopeful it will fix some problems with missing and stuck notes.
Len Ovens has been doing some cool work on “foldback busses”. Foldback is a slightly obscure term for what is more typically called “monitor mixes” - sending performers in-ear or on-stage submixes for them to listen to while performing. You’ll be able to do very sophisticated monitor mix configurations in 6.0.
What You’ve Really Been Waiting For
The big news, however, is that we are now getting very close to an alpha state. There are a few architectural issues still to solve, but we don’t plan to do any more feature development before 6.0.
We expect there to be many, many subtle bugs because of all the changes we’ve made to basic architecture over the last 2 years and more. We will be asking for as much help as possible (though not too much - this is still a very small development group!) to discover, analyze and resolve these bugs. Obviously we test along the way, but our testing is guaranteed not to have the wide coverage that our user community can provide.
If things go well with the remaining architectural issues, we might get to an alpha version within a couple of weeks. From there, it’s hard to say how long until the actual release of 6.0 - that will depend on the magnitude and scope of the bugs discovered during testing. But we are modestly optimistic that at least a beta version of 6.0 might appear before the end of this year.
