Ardour Development Update

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:

Cue Monitoring

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.

"Wet" Recording

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.

Varispeed

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.

Latency

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.

Transport Control

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.

Time

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.

Tempo

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.

Thanks for letting us know

Thanks for letting us know what's going on behind the scenes at the moment. All these features are great and I'm looking forward to seeing them in action in Ardour 6.0.

As the developer of a small open source project I realize what you are doing is a huge task and can take some time. Ardour has improved greatly over the years and as I have become accustomed to the logic of how Ardour works, I'm very pleased of most of the features. Still there is one thing I would like to make better: the undo system seems to sometimes behave unpredictably. I hope you could revisit the undo system and also uncouple the zoom level and timeline position of the last edit from undo. It is very confusing when Ardour jumps between zoom levels and timeline positions when undoing. Especially if you have scrolled to another place on the timeline or zoomed out and then when you undo the window jumps back to the zoom level and position of the last edit (that you did maybe a long time ago) and you lose your position in the session. It would be great if I could disable restoring edit window zoom level and timeline position when undoing things. This could be a option in the settings. Window zoom level and timeline position of the last edit could still be saved into undo history, but not put into effect when undoing if the user option was off.

This is the only remaining pain point for me when working with Ardour (I use undo a lot), everything else works well for me :)

Problem is, we couple them

Problem is, we couple them precisely because other people complain that "i undid an operation but i can't see it and i'm in totally the wrong place on the timeline".

Yes, another option is possible, but adding options for everything is not necessarily the right approach. Sometimes it is though.

@paul thanks for the detailed

@paul thanks for the detailed report. I am especially excited about your comment regarding MIDI, automation and audio being seamless. I can understand why such deep architectural changes have had to take place to make this all work.

Congratulations to the whole team!

Congratulations to you, Paul,

Congratulations to you, Paul, and the Ardour and Mixbus teams. This looks to be an amazing update. All of you have been largely responsible for proving that open source projects can really succeed! Very proud of you guys! Thank you!

Looks good. I'm trying to

Looks good. I'm trying to develop an amusement/aid for the brain-damaged (stroke victims with auditory verbal agnosia - i.e. AVA 'word deafness,' aphasia victims without AVA, etc), so your developments concerning Time and Tempo are very encouraging. I support Mixbus with my monthly amount plus purchases, so I believe that some of that comes to Ardour. Is that correct?

Yes, some part of the Mixbus

Yes, some part of the Mixbus revenue flows into supporting Ardour development, in more than one way. Supporting Mixbus is still a good way to support Ardour development too.

Hi! Is it possible to include

Hi! Is it possible to include linuxsampler by default in Ardour?

Re: linuxsampler: We would

Re: linuxsampler: We would have no desire to do that. Their license is also complicated (and possibly legally inconsistent).

Then how I can use gig and

Then how I can use gig and sfz format with my midikeyboard and ardour without compiling linuxsampler or use kxrepos, that often do not work?
P.S. I'm sorry for my English.

Ardour is a DAW, not a sample

Ardour is a DAW, not a sample library player. We can't fix all the problems with open source sample library players - we have enough of our own. Also, gig format is dead, even if there were some nice libraries that used it for a while.

@kohmkovm Have you tried

@kohmkovm Have you tried using Carla?

I have tried it. Crash all

I have tried it. Crash all system and does not work((

Pre-compiled binaries from KXstudio repositories.
Linux Mint 18.1 Cinnamon x 64

That is definitely not

That is definitely not normal. FalkTX is very active on linuxmusicians.com. You could try posting there to see if he can help you fix the problem. It may be something simple.

Thanks for info!

Thanks for info!