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.