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.
âAbyss