[Ardour-Users] development update, oct 2019

[Paul Davis]

(because not everybody checks discourse.ardour.org!)

Development Update, October 2019

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).
5cstudio.jpg4608×3456
<https://community.ardour.org/files/images/5cstudio.jpg>

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).
[image: ardour-virtual-keyboard-azerty]
ardour-virtual-keyboard-azerty.png788×265 24.6 KB
<https://discourse.ardour.org/uploads/default/original/1X/23956dca4459871c5f570b33e7ccf8d1f317c477.png>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20191101/d87033db/attachment.html>