What does multi-select actually do?

In the mixer window, what does multi-select actually do?

It doesn’t seem to actually DO anything. Which is fine of course, this project is in development but the response I got from the last post on multi-select implies that apart from fader control there should be some kind of action. It doesn’t appear to exist so I’m just curious as to why.

For now I’m happy to park the idea behind having it do anything useful, like fader control, apparently adding that feature would EXPLODE the sun and RUIN Ardour FOREVER! At least, that’s the impression I got after asking the two devs of this project haha

All I want to know is, fader control aside, what does multi-select actually purport to achieve? None of the buttons or knobs do anything and you can’t re-order tracks (that’s done in the side pane to the left).

For starters, track selection affects both views: Mixer and Editor. What is selected in one view is also selected in the other, and rightly so. So the question is really what is the purpose of multi-select in either view, to which one answer would be: so you can do some things on that multi-selection in the Editor view.

But you can do some things with a multi-selection in the Mixer view too. For example: many actions in Menu > Track, including Move Selected Tracks Up/Down (yes you can re-order multiple tracks at once), toggle Solo/Mute/Active, Remove and Duplicate.

Also, actions and scripts sometimes work on all selected tracks, or have the option to.

EDIT: And fader control does work, as somebody explained in your other thread: use the up and down arrow keys, not the mouse.

hey @johndev, thanks for responding so quickly! Hope you don’t mind my joke about reacting to my suggestions, I promise I’m not here to be a nuisance… well I am, but it will benefit the product and that’s all I really care about.

Ok so there seems to be some confusion here and also some layers:

  1. Sure, I understand that affecting one view affects the other that seems obvious and good

  2. In that case I suppose my gripe with moving tracks in the mixer window is that it isn’t drag and drop or available through a keystroke (oh wait there is and it doesn’t work either, a bug?). Which is fine of course and that’s obviously just a feature enhancement and not entirely critical.

  3. Ah unfortunately not, toggling any button/knob on multiple selected tracks (outside a group) doesn’t actually work. That may or may not be a bug (Ardour 6.9.0 on Arch Linux)

  4. Remove/duplicate does work but only through the menu option, not the delete button. So again a simple feature request and usability tweak.

  5. Re the up and down arrow keys on fader control, thank you I had actually forgotten about that piece of usability which is kind of more to the point: it’s not very usable, obvious, or quick.

  1. The key binding for moving tracks only works in the Editor. That’s the case for a few actions, including launching Lua scripts in slots 13-32.

  2. I’m not sure what that’s a response to. If it’s solo, mute, etc. then I was referring to the Menu > Track > Toggle XXX actions.

  1. Yeh looks like some features need to be synced across to the mixer window

  2. indeed solo/mute, it doesn’t work when pressing the channel buttons… ok so Menu > Track > Toggle XXX actions does work but yeh again… really not great usability. I suppose more features to request and/or implement.

I’m fairly certain that you’re Aidan from the YT comments under my video on clip launching. Given that you’re chosen to bring this discussion into our domain, I would politely ask you to keep your writing style here more civil than you did in that context. We rarely ban or kick anyone from this Discourse instance, but we do lock threads that get ugly.

To repeat again what I wrote there, it is not an accident that clicking on a mute button even when there are multiple tracks selected does not mute all selected tracks. It is an intentional design.

Perhaps you can make the case for a fundamental change in workflow such that things do work that way; we’re not inalterably opposed to it. But you will need to do better than you did in the YT comment section (assuming that was you), where you mostly just metaphorically waved your arms vigorously and insisted that it is OBVIOUS to do things the way you believe they should be.

Our belief is that even if action-follows-selection in the mixer is more “discoverable” than using groups and VCAs, it is rarely the case that the workflow is improved by using it. If there are multiple tracks that the user typically wants to mute/solo/rec-enable en-masse, they will be better served by putting them into a group. If they want to manage relative gain across a set of tracks (and possibly in a nested, heirarchical fashion), they are better off using VCAs than having “fader moves propagate across selection”. People tend to gravitate towards the first means they find of satisfying an end, and action-follows-selection in the mixer will tend to delay/obscure their discovery and use of groups and VCAs.

I know (from YT) that you believe action-follow-selection is so much more discoverable and important that we should ignore that and provide it anyway. You’re welcome to civilly argue the case for that (rather than just telling me/us that we don’t know what we’re doing). Maybe we’ll be convinced, maybe we won’t.

Also: re drag-n-drop for tracks. This is just something where we made a “strategic” decision years ago to not implement it because it is “hard”. When Waves Tracks Live was developed (it is basically just a reskinned version of Ardour), DnD tracks for the editor was done, but I didn’t like the visuals all that much, and so the change was never merged back into Ardour.

Hey Paul… sure, I feel like I made a pretty extensive and precise argument with good examples.

Regardless, I’m not here to misbehave and I want us to get along.

I apologize for my part in the comments section and for calling you a name, I could have handled that a lot better and I do mean that sincerely.

If it’s alright with you, shall we try again? I’m on your side mate, all I want is a good pro audio product for Linux and Ardour/MB is honestly the best I’ve ever seen.

Ok, hear goes…

As I said previously, with respect, that is intentionally bad design and contradictory logic. Hear me out.

You’re asking user’s to subscribe to an advanced (and better) workflow they might not know about, but obscuring usability for less advanced users. This could be less advanced audio users in the general, it could be new users to your program. Whatever the case, it only makes Ardour/MB look half-baked to the uninitiated.

I agree with you for the most part. The restricted and prescribed workflow/method, plus analog emu, is precisely why I purchased Mixbus 32C not 5 mins after opening my second session (more on that below). However despite my adherence to that ideology, forcing a particular method onto the user is not the way to convince them of that method. Ironically, that is the other half of my point.

These things slowed me down when they didn’t need to and introduced steps that don’t need to exist, until I make certain commitments with my session. Even then, there is always that set of disparate tracks that don’t really fit anywhere as a group or where I don’t want to group/VCA them. Especially now that you’ve introduced sampling capabilities, that is only going to become more obvious.

That aside…

I’ll use the example I gave in that YT comment: Reaper. The default scrolling functionality, what a confusing mess. Zoom by default and a Ctrl+scroll for common scrolling behaviour. Which would have been fine (it’s actually quite clever) but it took several hours to find it and also that it’s not documented or mentioned anywhere in their videos. Also there is no obvious way to change that default.

Even after finding that control, it frustrated me so much for basic usability that I simply came back to Ardour/MB where I was previously able to get a great mix in an afternoon without even thinking too much. That is of course where it became a personal preference rather than a universal truth but Reaper just got in my way without first proving the benefits of their method.

The only issues I had in Ardour/MB were the drag and drop and the multi-select + general lack of synchronicity with controls. All in all though, hassle-free.

But I digress…

It doesn’t really matter whether or not the workflow will be improved by the presence or absence of this feature. That is unfortunately not for the designers of a program to decide. What we are there to decide is how to increase the likelihood of that flow (which is your point), not put hurdles in the user’s way to achieve something very simple in the name of enforcing that workflow (which is my point). It’s an approach that only works for those in the know and leaves very little for those getting to know.

Aside from that, introducing these types of concepts and methods is something that people need to discover for themselves after understanding why they exist via their own experience. An experience which, and this is the crux of the problem, doesn’t happen without first having common and familiar functionality to breed the tendency for expansion.

As a really simple example of common convention in UX: this window I’m typing in isn’t Microsoft Word but ctrl+b still works to make the words bolded. (not sure if they started that but doesn’t really matter, everyone expects ctrl+b to bolden characters in a basic word editor)

What I assume you think you’re doing is coaxing the user towards a better way (VCAs and groups), which I understand and agree with as a principle. However, the way you’re doing it is deciding that is the way before they have had the chance to discover that themselves and then cutting off the path towards that conclusion. You’re expecting them to go from step 2 to 3 without allowing them to have step 1 first.

Having said all of that, I happen to agree with you. Absolutely, I would be better off putting things into groups and VCAs, which I do.

From a usability and logical pov, multi-select should truly mean multi-select. Anything that I do on a single channel in that selection should affect all channels selected. Even if we both agree that there is a better way, we also need to consider the basic tenets of good and consistent UX design. There should be a logical outcome to a feature i.e. if I multi-select something, I expect that to have an obvious and usable reasoning. If that reasoning means something gets in my way, then it shouldn’t exist.

In this way we can say that grouping is more of a permanent multi-select, it certainly shares the same visual feedback. Yet that same visual feedback doesn’t reflect the same functionality when used a little differently. That is fundamentally fractured UX design right there.

I try to live by the ideas of single-click design. Natural and intuitive user controls and most things should be one-click away. My team actually spends a lot of time designing interfaces and working with clients towards that goal. If the user has to ask us about basic usability or how to do things that are perhaps associated through some kind of convention, we redesign the interface to more closely reflect that convention whilst retaining the advantages that our interface provides. This is somewhat of an art form.

Like good stage lighting or good live audio: if we do our job correctly then no-one should notice.

Even if we disagree on everything I have just said, this functionality already exists as a keystroke. Muting/Soloing toggle exists in the menu. For multi-select. I therefore don’t understand why it’s disturbing the workflow to extend that same functionality to a mouse, which when we break it down is all I’m really asking for.

Re the DnD, yeh I absolutely hear you. It can be hard and maintainability + stability comes first. Still, it would be super great if eventually it existed in the codebase. From memory GTK+ has dnd via Motif and Xdnd and isn’t difficult if you lay out the signals logically. Obviously not critical.

Hey @paul, haven’t seen your response yet and I just realized it’s been exactly a month. Looking forward to hearing your thoughts on this issue.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.