Releases

MIDI Recording, Playback and Editing

The biggest single change in Ardour 3.0 over previous versions of the program is its ability to function as a fully-featured MIDI sequencer. Over the last several years, a variety of developers have worked hard to create a model for handling MIDI that is as integrated with Ardour's existing audio handling facilities and uses the same general workflow as much as possible.

ardour with MIDI tracks and data

MIDI Editing

Ardour's MIDI editing is based on a few basic principles:

  1. Editing should be done without having to enter a new window
  2. Editing should be able to carried out completely with the keyboard, or completely with the mouse, or with any combination of the two.

Currently, and in the initial 3.0 release, MIDI editing will be primarily restricted to note data. Other kinds of data (controller events, sysex data) are present and can be added and deleted, but not actually edited. Probably ...

MIDI Clock Sync

MIDI Clock is a stream of messages sent by a MIDI sequencer of some kind that indicates musical tempo. It is used to maintain a synchronized tempo for synthesizers that have BPM-dependent voices and also for arpeggiator synchronization. It does not transmit any location information (bar number or time code) and so must be used in conjunction with a positional reference (such as timecode) for complete sync.

Resizable Big Clock

Ardour 2.X had a "Big Clock" window that would display the playhead position in a large, highly visible font that could be easily seen some distance from your computer screen.

In Ardour 3.0, the Big Clock window can be dynamically resized, expanding the font size to any size you feel you need or want for your particular working situation. This can make remote operation via a MIDI or OSC control surface from another room much easier, for example.

Here is the default Big Clock size:

default big clock window

Visible per-channel phase invert buttons

In Ardour 2.X, there was an option to phase invert a track or bus hidden in the context menu for the track/bus name button at the top of a mixer strip.

In Ardour3, there is one phase invert button per channel visible in the mixer strip:

phase invert buttons in mixer strip

New Stereo Panner GUI

Although the panning GUI in Ardour 2.X was very powerful and flexible, it made the most common operations with 2in/2out panning more cumbersome than they should be. In Ardour 3.0, the old panners are used for many I/O configurations, but the special case of 2in/2out ("stereo") is now handled by a more deliberately designed GUI element, shown below:

stereo panner

Expanded Editor Cursor Set

The set of mouse cursors used in the editor window has been significantly expanded to provide more visual indication of what mouse operations (particularly drags) will do at any point in the window. Chris Goddard designed the set we are using, and the full collection is shown below:

editor mouse cursor images

New Solo Design and Features

In Ardour 2.x the solo system had complete separation between track and buss soloing. Any track that was solo'd would mute other tracks but not busses and visa versa.

Ardour 3.x introduces a more cohesive structure that not only links busses and tracks but also makes sure that the path to or from the solo'd track or buss is solo'd as well. As an example soloing a buss will also solo any tracks feeding it, and any busses it may feed into.

64bit timeline

Although Ardour has been 64-bit compatible since it was first written, it has had a limitation in that the maximum position on its timeline was limited by using a 32bit value for this purpose. At 48kHz, this limited the timeline to about 12hrs. In Ardour 3.0, all positions are stored in 64 bit values, meaning that there is essentially no meaningful limit to the length of the timeline. If you want to record a multi-day festival and put it all in one session, Ardour 3.0 will go there with you.

Improved Preferences Dialog

Ardour 3.0 splits preferences into two sections:

  • Settings that should logically apply to all sessions, because they are based on user workflow or system configuration
  • Settings that are per session, because they depend or reflect session content or design