Newbie RANT about Ardours’ GUI

[joseluisquiroga (joseluisquiroga@yahoo.com)]

Dear Ardour team. This is my

Newbie RANT about Ardours’ GUI.

Any edition application need basically three types of actions:

1. Navigation.
2. Selection.
3. Modification.

Those actions are done in most editing programs through the mouse and the keyboard.

Those set of actions are like a LANGUAGE that the user has to learn in order to control the program.

Ardour uses several kinds of concepts to edit sound: Tracks, Regions, Ranges, etc. Grouped by other kinds of concepts: mixing, editing, etc. Using different kinds of views and windows.

So from the point of view of a newbie like me, it is VERY important to keep that LANGUAGE of mouse and keyboard actions, that the user has to learn, as SIMPLE and CONSISTENT throughout the whole interface as possible. That allows a quick learning curve.

NAVIGATION.

Navigation with keyboard shortcuts SHOULD be done in EXACTLY the same way in EVERY context.

In any of these contexts:

• Navigating tracks.
• Navigating regions inside a track.
• Navigating midi notes inside a region.
• Navigating notes inside a notes list window.
• Navigating tracks inside a tracks list window.
• Navigating regions inside a regions list window.
• Navigating sources inside a sources list window.
• Navigating plugins or elements inside a mixer strip.
• Navigating elements inside any given context.

I should be able to use THE SAME actions in ANY of these contexts. After all they are all lists of elements.

Mouse, shortcuts or mixed actions for any of the following SHOULD be the SAME in any given context:

• zoom in ({ctrl +}{ctrl alt +})
• zoom out ({ctrl -}{ctrl alt -})
• nav up ({roll_up}{pg_up}{ctr pg_up}{ctr alt pg_up}{arrow_up}{ctrl arrow_up} etc)
• nav down ({roll_dwn}{pg_down}{ctr pg_down}{arrow_down}{ctrl arrow_down} etc)
• nav right ({→}{ctrl →}{alt →}{ctrl alt →}{end}{ctrl end}{ctrl alt end} etc)
• nav left ({←}{ctrl ←}{alt ←}{ctrl alt ←}{start}{ctrl start}{ctrl alt start} etc)

SUGGESTED actions borrowed from text editing, which is a very popular GUI “LANGUAGE”, are in parenthesis.

And that keyboard LANGUAGE for NAVIGATION should NEVER mix with the keyboard language for EDITION. That means that a shortcut for navigation should never be used to “nudge” a MIDI note, for example, because I end up editing when my intention was to just navigate.

The same goes for MOUSE actions. It should NOT be possible to just roll the middle button and EDIT (change the value) of what ever is UNDER the mouse pointer. It is very annoying that a common NAVIGATION action CHANGES the values under the pointer. Some additional or confirmation action SHOULD be needed.

All SIMPLE actions SHOULD be for NAVIGATION and NEVER for EDITION. Meaning that a simple drag of the mouse, without previous actions like double click or at least a 2-key shortcut, SHOULD NOT change anything. It usually happens to me that since the only option to select a region is to click it, and NO keyboard navigation allows me to select it, the click is taken as a drag and it ends up modifying the session. Also NO simple keyboard shortcuts, NONE, ZERO, like a single letter, SHOULD allow CHANGING the session. It is a door open for unwanted changes. That is why the GUI ends up with different mechanisms for “locking” changes.

All information about a session SHOULD be possible to obtain WITHOUT entering an EDITION mode. How come that if I want to know the velocity of a MIDI note I have to enter in EDITION mode? That is a call for unwanted changes. How come that if I open the MIDI notes list window, I can change its velocity and length just by rolling the middle button of the mouse? That is a call for unwanted changes.

NAVIGATION, at least with the keyboard, SHOULD be complete. Meaning I should NOT need to use the mouse to navigate any GUI context. Specially MIDI regions. But currently if I want to “page down” or “page up” a MIDI region to see the notes above or below what the “scroomer” is showing me I HAVE to use the mouse. Very annoying because the “scroomer” is not very precise. If I want to “page down” or “page up” the plugins in a Mixer Strip, I HAVE to use the mouse. Very annoying.

NAVIGATION should be omnipresent, simple and complete. So that you can look around WITHOUT changing anything. A 5 year old should be able to NAVIGATE the document, ups sorry the “session”, without accidentally modifying it because he accidentally pressed “E”, or “clicked” a little too long and ended up dragging something because it is the ONLY option to select something.

SELECTION.

Keeping the same idea as in navigation, a set of mouse actions and a set of keyboard actions, that SHOULD be DIFFERENT from the navigation ones, but common to ALL contexts, define a LANGUAGE for selection.

Selection SHOULD be also possible with keyboard shortcuts, and they SHOULD be the SAME for any context.

In any of these contexts:

• Selecting tracks.
• Selecting regions inside a track.
• Selecting midi notes inside a region.
• Selecting notes inside a notes list window.
• Selecting tracks inside a tracks list window.
• Selecting regions inside a regions list window.
• Selecting sources inside a sources list window.
• Selecting plugins or elements inside a mixer strip.
• Selecting elements inside any given context.

I should be able to use THE SAME actions in ANY of these contexts. After all they are all lists or tables of elements.

Mouse, shortcuts or mixed actions for any of the following SHOULD be the SAME in any given context:

• select up ({drag_up}{shift pg_up} {ctr shift pg_up} {shift arrow_up} {ctrl shift arrow_up} etc)
• select down ({drag_dwn}{shift pg_down} {ctr shift pg_down} {shift arrow_down} etc)
• select right ({drag_right}{shift →} {ctrl shift →} {ctrl shift →} {shift end} {ctrl shift end} etc)
• select left ({drag_left}{shift ←} {ctrl shift ←} {ctrl shift ←} {shift start} {ctrl shift start} etc)
• select element ({shift click} {ctrl click})

SUGGESTED actions borrowed from text editing, which is a very standardized GUI “LANGUAGE”, are in parenthesis.

EDITION.

Edition SHOULD be a COMPLEMENT to NAVIGATION and SELECTION. Edition should be only possible by INTENTIONAL actions.

That means that to MODIFY anything I SHOULD need to NAVIGATE to it, then SELECT it, and THEN do something else to modify it or to START modifying it.

In text editing it is mostly done by the famous copy/cut-paste ({ctr c}{ctr x}{ctr v}{ctr ins}{ctr supr} etc) driven by TWO and THREE combination of mouse actions or key shortcuts, NEVER by single key shortcuts or simple mouse actions. You pressed “K”? Ups you just CHANGED something.

The global behavior of the editing “LANGUAGE” SHOULD NOT be modifiable by simple actions of the mouse or the keyboard. You just rolled the middle mouse button because you were trying to NAVIGATE but you did it while your mouse was hovering over the edit mode selector? Ups, everything NOW seems IMPOSSIBLE to change because it is now in “lock” mode. That is a call for bug reports that are not bugs at all but just confusing behavior.

The user SHOULD be able to adapt the language in a very flexible way. The possibility of complex keyboard shortcuts allow that. For example if I am able to configure a {ctrl shift alt 3 2 1} shortcut.

In order to be able to have the SAME set of navigation and selection actions for any context, Ardour SHOULD have an action to enter the context of a single SELECTED element and get out of it. That should be possible both with the keyboard and the mouse.

That means I should need to do a double click or a 2 key shortcut to actually enter a context. So that I can use the SAME sets of actions for NAVIGATING, SELECTING and EDITING ANY given context.

A context could be as small as a length of a MIDI note in which I just type with the keyboard a value, or, AFTER entering the context, roll the middle button of the mouse, or drag the mouse around to make the desired CHANGE to the MIDI note.

NAVIGATION, SELECTION and EDITION SHOULD be completely DISJOINT actions. The way that is achieved in text edition is with the “caret” pointer. You NAVIGATE the “caret” to the POINT of EDITION. It is different from the mouse pointer so that the NAVIGATION and EDITION actions are DISJOINT.

In the case of a DAW like Ardour there SHOULD be an EDITION pointer SEPARATE from the PLAYHEAD which is for the point of reproduction (hence the name) and SEPARATE from the MOUSE pointer which SHOULD be JUST for navigation. It could even be just an special color maker for one and only one of the SELECTED elements of a context so that the user knows where the edition point is.

It seems to me that Ardour wants to let me NAVIGATE, PLAY the session, and eventually EDIT it at the SAME time. But without an actual EDITION pointer like the caret in text editors, or should I say the “edit cursor” of before Ardour 2.3 (which I never knew), it is not precise nor secure because I can accidentally change something that I did not intended to change.

And in ANY case if a modification is taking place the GUI SHOULD take me to the place of modification and SHOW to me the modification or at least give me some indication, like a confirmation dialog, of what and where is the CHANGE taking place.

It SHOULD NOT be ease to CHANGE something without having a VISUALIZATION of the CHANGE. That is a call for unwanted changes. So if I am changing something while reproducing, the PLAYHEAD should go its way but the GUI should no longer show me the position of the playhead but the position where the CHANGE is taking place, no matter what the default behavior has been configured for. Just like in text editors. And if there is a SEPARATE edition pointer like the caret of text editors, that behavior is easier to implement.

Currently in Ardour when the mouse is the edition point, it only tells me a “time” position. In some contexts like MIDI edition it is an horizontal position. So to actually paste a set of MIDI notes where I want them I have to first paste them and then move them around. So navigating MIDI should be precise and simple. With only the mouse pointer is neither. A simple, precise and powerful NAVIGATION of an edition pointer allows for an EDITION with the same characteristics.

The BEST open source audio application out there SHOULD be SIMPLER to learn and use.

I REALLY hope that the guys who actually make the choices (looking at Paul) for Ardour consider making it simpler for the newbie to learn and explore Ardour. Even a kid should be able to use it.

I am sorry if I was too harsh on all the GOOD work you have done over the years, or if I made mistakes about the actual behavior of Ardour, after all I am a newbie.

Having said my RANT, Ardour is THE choice over any other open source sound program because of … well … THE SOUND. So …

Thank you.

JLQ.

[jean-emmanuel]

On occasion I still get pretty decent mixes out of microsoft word 97…

[GuntherT]

What is the REASON for ALL the RANDOM capitalization USED throughout YOUR post? I found it highly distracting to the point I stopped reading before I made it to SELECTION.

If you have specific feature requests, you should submit them here (suggestions in the forum get lost quickly):

tracker.ardour.org

[F_D]

Stop saying “EDITION”, the word you want is “editing”. Edition is a completely different word.

[BenLoftis (Ben)]

@JLQ: I am increasingly responsible for some of those GUI & behavior issues, so I’d like to address some of your comments.

Firstly, I agree 100% with you, in principle.

In practice, there are a few roadblocks to achieving your goals.

The first, rather obvious one, is history: every time we add or remove a keybinding or feature, we get some pushback from people who have mastered the current behavior and don’t want it to change. This is especially annoying when most things work the same as before, but just a few things change with each release. It would arguably be nicer to change the whole GUI, in one fell swoop. But we have neither the resources nor the desire to do that.

The second roadblock is … well … the devil is in the details. It’s nice to say that no unmodified key should affect the session, but do you really want to require a modifier to add a marker? It’s nice to say that navigation and edition should be independent from selection, but when you consider the nested complexity (a selected midi note which is in a region which is in a track…) this is hard to resolve. It’s nice to say that a mouse-wheel should never do anything other than scrolling, but it is nice to adjust a knob-value with the wheel. How do you resolve the fact that some shortcuts (transport stuff) should be entirely global and unchanged, while some dialog boxes (virtual midi keyboard?) sole reason for existence is to do something else with those same keys?

Given those practical problems, here are some of the toplevel changes that are underway, to move towards your goal:

1. Context:

In the beginning, Ardour had only a single window where you recorded, edited, and (presumably) mixed. We are moving towards a model where there is a dedicated page for tasks: currently we have Rec(ord), Cue, Edit, and Mix. This additional context might allow the user to access more single-key shortcuts in the Edit window, but allow the task of Recording to be safe from accidentally nudging or trimming a region with a shortcut.

2. Object Properties:

Ardour has long avoided the convention of similar software where selecting an item (track, region, plugin, etc) also exposes a property-pane, or sub-editor, where the item can be interrogated and manipulated. We are taking some steps towards that. And this also provides a clearer context for shortcuts and actions. If you select a region and it appears in a property sub-editor, it is more obvious that you intend to make ‘editions’ there.

Obviously there’s a tradeoff here: we can’t lose Ardour’s overall feel. Ardour allows power-users to do whatever they want, even if “what they want” is to shoot their foot off.

My tentative plan is that the Editor window will continue to be the “place where power-users can do nearly everything from one screen”, whereas other editor-adjacent tasks (recording, automation?) might have dedicated pages that are more context-sensitive.

-Ben

[seablade]

And thank you Ben for jumping in, as you probably put it clearer than I might have, but to expand a bit on at least one point:

No unmodified key should affect the session

I would strongly disagree with this. I understand it does make it easier for a newcomer, but it VERY much limits a more advanced user, and more importantly, very much slows down more advanced users. Part of my general workflow requires this, and is able to be pulled off because it doesn’t require modifiers:

P - Move Playhead to Mouse
S- Split the currently selected regions at the edit point (Will try to come back to this in a moment)
J/K - Trim the currently selected region to the edit point

Those functions by themselves are incredibly powerful, provide probably 90% of the editing workflow, and are completely unmodified. I use more than this, but these are probably 90 % of the time I spend actually editing the session can be summed up by these commands and basic region movement/manipulation with the mouse.

One thing to keep in mind, is that the UI of Ardour, and in fact many pieces of software, is interacted with not just by the keyboard, or just by the mouse, but rather it is designed for interaction with both simultaneously. One hand on the mouse and one hand on the keyboard. This is a more difficult learning curve for newcomers especially yes, but it is much more powerful and speedy for advanced users as well.

As Ben mentioned, the thing to keep in mind is that most of these functions have come about because they are asked for by advanced users, and there is a workflow gap between a newcomer and a more advanced user. This is true in any software I have worked in, I am often going (Why does it work like this, or why doesn’t it work like this) when in actuality there is method to the madness for certain workflows that makes far more sense.

And in the end the professional user, tends to be the more advanced user, and for them time is money, meaning that saving an hour off editing a session by utilizing the above, is literally money in their pocket or not, or increasing the chances of getting the next job because they were able to save money for the client and get results, etc.

  Seablade

[seablade]

@joseluisquiroga

In the case of a DAW like Ardour there SHOULD be an EDITION pointer SEPARATE from the PLAYHEAD which is for the point of reproduction (hence the name) and SEPARATE from the MOUSE pointer which SHOULD be JUST for navigation. It could even be just an special color maker for one and only one of the SELECTED elements of a context so that the user knows where the edition point is.

So I believe you meant to put EDITOR pointer, not EDITION.

Funnily enough Ardour used to have a dedicated edit marker just like you describe. It was found to be far MORE confusing for the average user, and didn’t do much to improve workflow for the more advanced users.

   Seablade

[BenLoftis (Ben)]

It’s worth mentioning that Ardour has a menu pulldown to select the “edit point”.

The edit point can be either:

A) the mouse: this meets most users’ expectations that you are going to operate where the mouse is. clicking ‘split’ will split the region where you are pointing with the mouse. Note that, when snap is enabled, there is a blue (sic) line which indicates where the actual split will occur, which might be slightly to either side of the mouse depending on which grid line you are closest to.

B) the playhead: this slightly more advanced feature is useful when you want to make edits ‘by ear’. you can roll the transport and press the ‘s’ button to split a region in realtime. Or start and and a range-selection which you can later delete, loop over, or whatever. Editing by ear is particularly useful in classical recordings where the waveform might not provide any visible clues on where to cut; it is also necessarily the only way you can edit, if you are using a remote controller with a jog wheel or whatever.

-Ben

[Alkukoira (AlkuK)]

Good points, man. Re: “history” - a clean slate (ver. 8?) is universally understood as a solvent, I believe.

Regressive ant-minds tend to mock and rave no matter the proceedings.

Intuitively, Ardour is not very intuitive for new users… Peace.

[paul (Paul Davis)]

How many times do I have to repost this link to try to discourage the use of the term intuitive?

Reflections on "Intuitive"

People sometimes criticize a piece of software as being "unintuitive". In fact, its one of the most common complaints you'll hear whenever anyone starts using a new piece of software. Its often entirely justified too - its rare that a complex application manages to be obvious to every new user, or even most new users. Some software developers have a good track record here, Apple in particular, whose rules and guidelines for how to design user interfaces keeps on manage to churn out remarkably i…

What people find intuitive when using computer software (and many other human tools) is largely a function of their previous experience. It is not inherent to human beings, or computer software. Many expert UI/UX designers know and understand this, many of them have even written about it.

[cooltehno]

@joseluisquiroga

the PLAYHEAD should go its way but the GUI should no longer show me the position of the playhead but the position where the CHANGE is taking place

Shift+F & Ctrl+F combinations solves the need

@BenLoftis

currently we have Rec(ord), Cue, Edit, and Mix.

(Related propose) AFAIK there are Alt+M, Alt+R, Alt+C combinations to toggle between. May be it would be comfortable to add something like Alt+E to toggle Editor, because for example if I’m in the Rec or in the Cue and want to switch straight to the Editor - I need to toggle Alt+M twice.
(Current Alt+E combination is busy with Export function, may be need to sacrifice to keep the same context of “Alt”)

@Alkukoira

for new users… Peace.

“a new user with the old habits”. If I didn’t have experienced with the Cubase for example - I couldn’t know what to compare - I couldn’t feel uncomfortable with a new program. Now my habits are on the Ardour’s side - I find them comfortable. :))

[Alkukoira (AlkuK)]

The heart of the issue is balance. A balance between new and old. Favoring either old or new leads to imbalanced development.

[jean-emmanuel]

I think part of the problem is that people tend to blame a lack of intuitiveness when there’s a much bigger thing at play : some things in life must be learned and yes, it takes time. Would anyone argue that a guitar or a drumset is unintuitive ? Yet it takes years, even decades of practice to produce anything decent out of an instrument, and there’s nothing natural about all the micro movements and reflexes one has to learn to get there. Is a simple tool like a hammer intuitive ? Maybe, if you only need to pin some random nail, but what about actually building something with it ? Sometimes we just have to be a little humble and take the long way : reading the manual, trying, failing, reading the manual again, getting better, failing again, reaching out to real humans for help, and at times making constructive suggestions to improve everyone’s experience based on one’s actual experience… doesn’t this sound much more rewarding than ranting all about intuitiveness ?

[paul (Paul Davis)]

Absolutely. But there’s even more to it than that.

The number of possible basic workflows with a DAW is quite large. Most users (rightly) consider their particular way of doing things to be the obvious one, even though the common operations (and even concepts) for each of them may vary quite a lot.

Some people may start by importing pre-existing samples, rarely trimming or splitting them, spending most of their time arranging them relative to a musical grid.

Some people may start by recording a person (perhaps themselves) performing on a physical instrument, and then overdubbing that, with significant trimming and splicing of diffferent performances, largely ignoring any “grid” and never touching MIDI.

Some people may start by mouse-clicking in MIDI notes, never have any audio data on the timeline, never require any audio tools, do a lot of region duplication-then-edit, and rely immensely on synthesis plugins and FX.

Some people may start with an import of an entire pre-recorded multi-track session, with the goal of mixing/mastering it. They will perform no editing at all, spend all their time in the mixer window, working with a small number of plugins, endlessly tweaking their parameters, and perhaps making heavy use of automation.

Of course, many users will combine some or all of the above, and/or follow pathways of their own. Creating a piece of software that performs all of the above in an “intuitive” way is almost impossible - anyone who finds a given DAW “intuitive” for their workflow is likely in for a shock when they switch to a different workflow. But of course, at that point they will have invested some real time in the program, and are likely willing to learn how to do X as long as it reasonably well documented somewhere.

[Alkukoira (AlkuK)]

Yes. Good points. Technically, a piece of software could be customized to serve the difference in users, thru differing templates and the like. Is this far off for Ardour, who knows… All the best in decision-making.

[Orlev]

But the piano is intuitive…

[Bruno_Unna]

Of course you’re right, Paul. Yet:

The point you make about software in particular, and tools in general, is applicable to anything with which humans can interact. The qualities of any experience largely depend on previous experience. Does that mean that we should ban the word “intuitive” from the dictionary? I don’t think so. Or that the concept of intuition is so subjective that trying to reach a consensus (objectifying it effectively) is ridiculous? This is more likely, but still hard to buy for me.

Obviously, reliance on previous experience, being the base for the useful application of intuition in new situations, is the strength of the human mind that we should be aiming for when designing new interfaces (e.g. that’s how an Amazon Kindle, for example, resorts to analogies with paper books). A music sequencer, more often than not, displays a piano keyboard that makes it intuitive (please forgive me here) that the vertical dimension of the screen accounts for the note being added.

What I’ll agree with you in is that the more abstract the concept, the more difficult it is to rely on to build up intuition. And in that discussion over which of two very abstract things is more intuitive is so subjective that it quickly becomes a moot point.

A quick note regarding the tone, if I may: I think that I can see why you feel frustrated having to repeat the same message over and over again. But there will always be “newbies” for Ardour (or so I hope). And it’s not a trivial piece of software to master. So I’m afraid that the tone you’ve used may be discouraging for people trying to bring new ideas to the table, specially coming from the prominent figure that you are as regards Ardour.

Very warm regards.