Newbie Critique of the Ardour 7 Interface with Emphasis on Log Errors and Snapshots

I am using Ardour 7.3 with PipeWire on Debian 12. I just finished the Ardour 7 tutorial as downloaded on 16 September 2023. I have only used Ardour 7.3 to learn how to use Ardour 7.3. My overall impression of the Ardour 7 interface is that it is aesthetically and functionally very good. The density of functionality in the Ardour 7 interface is quite navigable, though it might not be obvious to the uninitiated. The tutorial fills the gap very nicely. I prefer the desktop XFCE for its similar philosophy of design.

This is only my opinion, and it comes with no warranty. I am not yet comfortable with the recorder and cue windows, so it’s not like I know what I am doing, but that could be a helpful perspective. Two and only two elements of the Ardour 7.3 interface strike me as uncomfortable: (1) the flashing red log light and scary red error messages, (2) the confusing terminology of ‘session’ and ‘snapshot’.

The flashing red log light is designed to grab my attention, and it does—too many times. Those red error messages are laconic and for the uninitiated they are cryptic. It is unnerving after the first few times. I can only worry that I am too dumb to use Ardour 7 or that Ardour 7 is too buggy. I don’t have a clue how many people use Ardour, but it has been around for more than a decade, has the blessing of the Debian Community, and seems to be useful to its aficionados for meaningful work.

If there were some handy explanation of those error messages, the whole flashy red log light would be far less intimidating. Maybe the error messages could be linked to an explanation of its type of error. Maybe the list of current error types could be shown in the order encountered with links/tabs to their descriptions. Maybe the error explanations could live in the source code and be automatically compiled into useful documentation.

I am an amateur but talented nonfiction writer. I’ve put in the years, and I can’t help but critique the writing I read. Of course, vocabulary is fundamental. I assert that a ‘session’ is a gathering of one or more people to create music, whether live or recorded. The session of Ardour parlance is really a project, even a typical ‘file’ if one does not look too closely at implementation. A directory may be construed as a special kind of file. I assert that a ‘snapshot’ is a fixed record of state. The snapshot of Ardour parlance is a session, at least sometimes. This is all very confusing.

In Ardour 7.3, the two snapshot menu entries of the ‘Session’ menu are ‘Snapshot (& keep working on current version)…’ and ‘Snapshot (& switch to new version)…’. We know that’s not clear. If I entertain the concept of entities that can be ‘sessions’ or ‘snapshots’ with state transitions, then I would suggest the alternative menu entries ‘Snapshot to inactive record…’ and ‘Snapshot to active composition…’, respectively.

Snapshots are listed under the ‘Snapshots’ tab of the Editor List panel. I think the active entity should be clearly identified as the active entity. Perhaps the ‘Active Composition’ could be listed under that heading and the other entities could be listed below under the heading ‘Inactive Snapshots’.

I think the session-project-snapshot hybrid is semantically nebulous and therefore problematic, no matter how you code it. The special treatment of the default session-snapshot with the same name as the session-project is additonal semantic confusion. The session-project data implementation has a top-level project directory and XML files with the suffix ‘.ardour’ for the namesake session-snapshot and any other snapshots. It seems to me that the session-project name should correspond, as it does, to the top-level directory name, but I don’t think the Ardour ‘session’ name should also define a base name for a special and also typical configuration/data file, in this case the original XML file with the .ardour extension.

There are two semantic remedies: (1) Either define the session-snapshot thingy as one uniform thing, e.g. ‘revision’, or (2) define two separate things so that the active composition is not a snapshot and the snapshot is not an active composition. If the latter remedy is chosen, then the term snapshot must be isolated to what the word means, snapshot data should probably have its own file extension (e.g. ‘.adsh’), and the current data thingy requires some proper definition and a proper name. If you can’t guess, I really dislike the term ‘session’ to mean (not even all the time) the active digital composition.

If there were active and inactive revision entities of the project (i.e. of the ‘session’ and the top-level data directory), the items of the ‘Session’ menu could read: ‘Copy the current composition to an inactive revision…’ and ‘Set a revision to the active composition…’. Not only might a new revision be defined, but if desired an existing revision could be redefined.

If there were snapshots proper, then snapshots could not be edited but could be deleted and perhaps overwritten, snapshots would perhaps have individual data files with a distinguishing file extension, and there would be also be a singular active composition proper (maybe in memory or maybe with its own file with basename from the project-session name and a unique file extension).

If snapshots were strictly snapshots, the entries under the ‘Session’ menu could read: ‘Current composition to snapshot…’ and ‘Snapshot to current composition…’. The current and active composition would not be a named entity to list in the Editor List under the tab ‘Snapshots’. It would be saved implicitly as or with ‘the session’ in the typical save-the-application-file way.


As a n00b user (switching from Reaper for radio work just these days), I would like to parrot that. This red light does create some confusion or doubt for a beginner. Also, since the light is red, my brain always seems to want to click on it.

Maybe add an option in the Preferences to turn off the logging, or to hide the UI button entirely?

Other than that, I think Ardour’s UI is really well polished over the years. In particular, I like how most buttons are text-based (so the users won’t get too many visual symbols, which they, depending on the taste, may or may not like).

That said, since my main task is radio show editing, I would probably hide all toolbars (leaving me only with the waveforms + maybe summary view, more or less) if there was an option for this. I would also make the track panel as narrow as possible – or, ideally, simply toggle it on or off entirely when needed (I imagine this is also easiest to implement?). All this would help with maintaining focus.

Audacity has incorporated some of this long ago (I can create a fairly “bare”, waveform-only view), but in Ardour, keeping the main toolbar always visible is quite apparently a decision of the dev team. The GUI is not as modular. With a deep respect towards all devs (and, obviously, Ardour doesn’t have to be Audacity) – has there been in-depth discussion on this in older forum threads? Would be interesting to read about the rationale for a newbie.

Thanks for your careful parsing of the terms in the Ardour UI. I was at first prepared to skip over it (in my hubris as a long-time user), but I find your thoughtful analysis calms that knee-jerk response.

As a software developer, I too find the idea that a “snapshot” is a thing I might continue to edit problematic. In my mind, the term “snapshot” implies something more like a “tag” than a “branch”. (in version control terms).

I don’t have the time or energy right now to respond more thoroughly, but I would like to mention a way of thinking about Ardour that grows in significance within my own mind:

The long term goal of this project (ignoring details like licensing, source availability etc.) is to get to a situation where there are no objective reasons for not choosing this DAW over any other. Obviously, there will always be subjective reasons for doing so - colors, layout, terminology, details of particular workflow etc.

Does this fit into the category of “an objective reason to not choose this DAW”, or “a subjective reason why I don’t feel fully positive about using this DAW” ?

I am not saying that we will never work on the subjective stuff until the objective stuff is complete (it may never be). But in terms of prioritization, the objective stuff - all the things that you cannot do in Ardour but can do in at least one or two other DAWs - will remain much more important.


Also, I will note that if this stuff really bothers someone, Ardour is fully translatable, and you can create your own translation that does nothing but handle Session → Project and Snapshot → Whatever You Prefer.


I love having a debug log that is as detailed as possible.
This is used to improve the software… to provide better information and error reporting.
I leave messages like “an error has occurred and the system will shut down” to Windows users.


Re: the snapshots - I thought it was pretty clear what they meant. Ardour is open source. You can always change the menu item text if you want to dig in and do a little work on it.

1 Like

Hi, there!

I have the same system here. Where did you get that tutorial? I’ve been using Ardour from intuition and would like to have some formal training to get out the most of it.

Thanks in advance.

Best, Alexandre

@lymber, Ardour, Help → Tutorial is a link to the online tutorial. You might care about thread “Localized File System Version of Ardour 7 Tutorial”, Localized File System Version of Ardour 7 Tutorial .