Hey, Paul here. I’ve become a little concerned that the public impression of Ardour recently has been dominated by cases of entirely valid bug reports that go unnoticed and unresolved. Someone who is not quite connected to our development process might understandably get the sense that we’ve stopped working on the software.
This is absolutely not the case. Instead, what has been going on is that for the last several months, both myself and @x42 have been involved in work that has no immediate payoff for Ardour but we believe has long term significance. This has been going on in several development “branches”, and below I’ll go over these branches and what we’re up to:
-
“Pianorule” : this branch contains a massive refactoring and rearrangement of code so that we can implement MIDI editing anywhere we feel like it, without duplicating code. This is primarily focused on providing a MIDI editor for the cue (“clip”) page, but may later make it feasible to add a standalone “piano roll editor”. This branch is currently stuck because the changes have exposed that the (hidden) assumption that the left edge of the editor track canvas is zero on the timeline has turned into a much more pervasive part of our code than was ever intended.
-
“cliprec” : this branch is rather young but is a test bed for ideas about how to do clip recording in Ardour. This is surprisingly hard to do correctly, mostly because of assumptions and decisions that go back to the early 2000s. We have some good ideas though, and I’m optimistic that the experiments going on will land successfully.
-
a “new” DAW focused on front-of-house operations : this is where @paul has been focused for much of the last month, and is a resuscitation of the ideas behind Waves Tracks Live, a commercial GPL’ed product from about 2015 that was based on Ardour. There is a vague idea that this will become an additional DAW available from both ardour.org and also from other commercial partners. The main idea for WTL is that is a “front-of-house” recording tool for live sound engineers. It has no plugin support, no MIDI support, and is massively simpler to use than Ardour. It also has a clever trick to help with so-called virtual soundchecks, where you use a recording of a previous live gig to do most of the work for a soundcheck at the current one.
-
“mode-clamping” : this is where experiments with adding ideas orbiting the concept of “this thing has a scale” are happening. This is much more complex than most people imagine when they voice their desire to “tell Ardour what scale I’m using”. Lots and lots of music from all over the world doesn’t work with scales in a simplistic way (even a lot of western pop). Currently the most promising idea is a heirarchy of objects that can each have their own scale, starting at the session level and going all the way down to individual regions. If a scale is not assigned, an object inherits one from its parent (ultimately the session).
-
“region-fx” : @x42 has been busy with adding per-region plugins in this branch, and it is currently being tested/evaluated by some of our early beta-testers.
On top of all this, both myself and @x42 were quite involved in the work done on Ardour to provide support for Dolby Atmos now present in Harrison Mixbus 10. Sadly because Atmos is proprietary technology, Ardour itself cannot use this work at present. Nevertheless, we designed things so that should somebody create something broadly equivalent that is GPL compatible, it would be relatively easy to make it work with Ardour.
So, that’s what’s going on in the background. All this stuff does tend to mean that most new bug reports are not being attended to, and many already-known bugs too. Obviously if we had a larger development group, we could be doing both types of things, but we don’t, and so we aren’t. I’m not offering to change what we do, but let us know what you think of this prioritization/allocation of resources.
30 posts - 19 participants
Read full topic
