It's been a long time since the last release of Ardour, and there's still no schedule or even vague sense of when the next release might appear. I (Paul) felt that our users, and particularly our subscribers, deserved some information about what is and has been going on with development over the last 8 months. I had promised to do this back in December, and it is now long overdue.
The core developers of Ardour (myself and Robin Gareus, with help from Ben Loftis) have been involved in some major architectural redesigns of Ardour's internals. We didn't really plan on this as a distinct goal on its own, but rather these changes emerged out of the desire/need to add new functionality and fix fundamental issues with the program. In most cases, these changes don't have any particularly noticeable effect on the GUI (Grid/Snap changes are an exception). Nevertheless, they lay the ground work for more interesting and more visible changes, as well as new functionality in the future.
First, let me mention the long term "big picture" goals that we're working towards:
- Improving workflow for all common operations, and many less common ones.
- Integrating MIDI and audio as seamlessly as possible, so that users rarely need to consider the type of data they are working with. We'd like to extend this to automation data too.
- Providing fast pathways to getting groove-centric sessions set up, with pattern generators and other related tools.
- More use of "flexible" time aka timestretching throughout the editing process, if desired.
- Fixing bugs.
- Reducing complexity and increasing discoverability.
So far, we've done substantial work in these areas of Ardour's architecture:
Ardour 5.12 allows you to monitor (listen) to either the input signal to a track, or the existing material on disk for the track, but not both. This is generally acceptable when working with audio, because overdubbing works the way most people expect it to. But when working with MIDI, it is less than ideal - many users expect to be able to use a MIDI controller (e.g. a keyboard) and generate new sound from the synthesizer in a track at the same time as listening to whatever has already been recorded for that track. Being able to listen to both the input signal and the existing recorded material is often called "cue monitoring", and this is now possible in the development code.
As part of the changes for cue monitoring, the work involved in playback from disk and recording disk has been split into two "processors", which are the basic type of objects you can see in Ardour's mixer signal flow. Processors you already know include the gain fader, plugins, sends, inserts etc. Now, recording and playback are just processors too, which means that they can be reordered in the signal flow. This allows you to (optionally) record after one or more plugins, often referred to as a "wet recording" (dry recording means without any FX). We think that some users will find this side-effect of splitting up recording and playback to be quite powerful in some settings.
Splitting playback and recording into two processors per track led us to re-examine Ardour's mechanism for varispeed playback. This is used both by the shuttle control, and also when syncing to an external positional reference such as LTC or MTC. We decided to move this functionality into a total different "level" of the program internally, so that the core of the code no longer has to pay any attention to it at all. Varispeeding is applied to all data flowing in and out of the program, totally transparently to the rest of the program. This redesign makes a few new tricks possible, such as varispeed recording, and having MIDI synth output pitch-shift alongside disk-based audio. The quality of the resampling engine has gone up dramatically too, since we have switched from simple cubic interpolation to using Fons Adriansen's excellent zita-resample code.
Ardour has had plugin latency compensation dating back to almost the first release of the program. But that compensation was limited to tracks (not busses), and didn't cover other cases where latency is introduced into signal flow. Robin (Dr. Gareus to the rest of us) redesigned almost every aspect of the core of Ardour's processing code to now provide latency compensation everywhere. This isn't like some DAWs in which "more things now work". Latency is now compensated for no matter where it happens, completely and always.
The changes to support full latency compensation revealed some conceptual and implementation issues with the way transport control operates inside the code. Looping and starting/stopping become much more complex when taking latency fully into account. Fixing this has meant a redesign in which every processor in a track or bus is told precisely which part of the timeline it is expected to be working on, among several other deep and difficult changes.
There is a lot of work to do on Ardour's MIDI workflow. But before that can happen, there are several subtle errors that are caused by the way released versions of Ardour have handled musical time. When you edit and move a MIDI note forward by a quarter note, that process would actually involve several conversions back and forth between time measured in samples and time measured in musical units, and the result is (often) small errors accumulating that lead to the note beginning and end being "wrong".
Changing this has been a mammoth task. Everything that has a position and/or a duration within the program - a rather common feature in an application partly there to place and edit things along a timeline - has needed to be tweaked to use the correct time units at the right time.
One of the goals of the work on representing time has been to move towards more flexible tempo maps, specifically ones that do two things:
- not regard musical (Bar|Beat|Tick) times as deterministic
- flexibly follow human performance more easily
Users should be able to put the musical time 1|1|0 wherever they need
to, and in fact may want to have more than one such time in a given
session. They may also want to adjust where the 12th bar starts, or
any other bar for that matter. There may be rubato sections where
musical time (counting) effectively stops. We want to be able to offer
automated analysis and human editing that can easily conform a tempo
map to a human performance, so that later tempo map driven editing
will fit it precisely.
This work has been ... is ... challenging.
Grid vs. Snap
In the released versions of Ardour, we noticed that users are often confused by the Grid. Sometimes the Grid appears to do nothing, and sometimes it does something unexpected. Furthermore, it required a lot of switching between grid modes: if you were snapping to 16th notes, then you had to switch the grid mode if you wanted to snap to a marker.
The "Grid" has been separated into 2 separate features: Snap and Grid.
When "Snap" is enabled, any mouse operation (like splitting or dragging a region) will be "resolved" to a snap target, if one is near. Snap targets can be any of: the nearest marker, the nearest region start/end, or the Grid. It is now possible to select multiple snap targets simultaneously. So, for example, you can choose to snap to both Markers and the Grid.
All snapping is now "magnetic"; and you can no longer snap to a target that is off-screen.
Finally, there is a new "snapped cursor" ( a blue line ) which indicates where the next mouse action will occur, if it isn’t directly under the mouse. This is particularly useful when splitting regions: the blue line indicates where the split will occur, if a snap is in effect. In the prior operation, a split could happen quite far from the mouse, if a snap target was applied.
When a "Grid" is selected, then vertical lines will appear on the editor canvas, extending down from the timeline ruler at the top of the editor. If Snap to Grid is enabled, then these lines will indicate the possible snap locations for your mouse actions.
In the released versions of Ardour, there is no connection between the zoom level in the editor and the grid. If the snap grid is set to Beats, then it may be quite unclear what snap is actually doing. If you were zoomed out, then the visual indication of individual beats might disappear, and yet you were still snapping to them. If you were zoomed in too close, then you might snap to a beat that is offscreen (and therefore invisible)
We've reworked this so that the grid always takes the visual zoom level into account, and the visual grid lines will be generated to sensibly match your current zoom level. For example: if you have a grid set to 16ths, but you are zoomed far out, then lines will only appear on bar lines. Inversely, if you've selected "bars" for the grid, but you zoom in very close, we won't draw the quarter- or 16th-note grid lines, because you didn’t request grid marks at that level.
All of these changes should result in a more consistent, "what you see is what you get" operation for Grid and Snap.