Suggestions to improve MIDI workflow in Ardour v7

Community Ideas for Ardour
#21

I think the current implementation of MIDI editing is powerful and a step above the separate window most DAWs use. As someone who is primarily a software-based producer and works with MIDI frequently, being able to select and perform operations across multiple inline rolls is a significant workflow feature for me. While I don’t see any inherent issue from allowing rolls or regions to be in a separate window, I think it would be better to focus on fixing the current usability issues people have with inline editing. From my view a separate window is a less flexible editing style and seems to only be requested because of these issues users have with the way inline editing is currently handled. I think if these issues were resolved, more people would prefer the inline editing style.

To touch on some of the suggestions in the OP:

remember the last selected track type

This is a good suggestion, I think it would be nice if we could also use modifier keys on the track list in combination with right clicks to pre-select a specific track type to add. Shift + right click for audio, Ctrl + right click for MIDI, etc.

default note velocity should be 127.

The initial default velocity should be kept the same. Many sampled instruments use relatively unaltered recordings, if the sampler is defaulted to 0db, sample playback can be well above digital zero at max velocity. This could be an issue for inexperienced users who don’t realize they have to reduce velocity or volume levels. Users should instead have the option to set their own default in the MIDI section under preferences.

make scrolling the mouse wheel scroll up and down

The main issue I see with this is that someone will run into the opposite problem, wanting to scroll the track list but being forced to scroll the roll instead and having to move their mouse over to the track list. I think a better solution would be to use modifier keys with the scroll wheel to handle scrolling the roll, similar to the way alt, shift and ctrl are currently used to expand tracks and expand/compress the timeline.

when scrolling with mousewheel to change velocity before drawing a new note, keep this new velocity value for drawing further notes

This is currently the way velocity is handled in the latest release.

double clicking inside a MIDI track creates a new 4-bar MIDI region, starting with the bar that has been double-clicked

I think this is a good suggestion, currently double-clicking opens up the track properties, which I rarely need to open, it would be nice if it was instead used for more context-sensitive editing operations, again with modifier keys to handle controlling which modes are entered, or zoom levels, along with the option to set a default.

2 Likes
#22

Learning and using keyboard shortcuts or constantly switching mouse modifier modes with buttons for such simple and often used tasks is a slow, unergonomic implementation that no new user would simply try to do.

Learning and using the keyboard shortcuts of any complex software is essential to efficient workflow and is something every user should aim to do. I see no reason Ardour’s interface should cater to users who aren’t willing to take the time to read the introductory section of the manual or follow the tutorial, both of which explains key concepts of its usage. Perhaps a big window should pop open on first run with big buttons linking to the tutorial and the manual so people are more inclined to read them, but I feel the same people who aren’t willing to open the help menu in the toolbar would also just skip right past these anyways.

The modal editing paradigm is by no means a new concept in DAWs or other software, I personally prefer it over the highly context-sensitive uni-mode paradigm a lot of software today strives for. In my own experience fiddling with a highly-context sensitive pointer for operations can be frustrating and I’ve found common operations end up in a context menu because you just can’t fit everything into one mode, in a proper modal paradigm they would be made available easily and you can leverage the power of modifiers more effectively based on the mode. It’s really not difficult to remember a few simple keybinds to enter different modes. It has a steeper learning curve, but ultimately it’s the better paradigm when you’re dealing with complex software like a DAW that has many different editing operations to perform.

2 Likes
#23

The double click to create a MIDI region idea is gold. Can you add that to the issue tracker linked earlier in the thread by Beth so it doesn’t get lost here?

Also addressing the hotkeys, I added an issue to have them viewable in the mouse-over popup tooltip. That would have lessened my learning curve dramatically, but those same users who don’t read the documentation are not likely to read the tooltip either.

2 Likes
#24

@whitewolfmusic included the double-click function in the issue.

#25

in a proper modal paradigm [common operations] would be made available easily and you can leverage the power of modifiers more effectively based on the mode.

I share your sentiments on modes to an extent. All the same, there is something a bit odd about Ardour’s modes.

The grab mode selects and moves objects, according to the tooltip, but in reality it only moves regions; something you discover as soon as you try to drag a note.

The range mode doesn’t interact with objects in the timeline at all, but the timeline itself.

The cut mode could split notes, but it only splits regions.

The audition mode only auditions regions, and only the whole region at that.

The stretch mode time stretches regions if you perform the necessary incantations; otherwise it transforms into the grab mode and moves regions instead.

The draw mode is uncharacteristically intuitive, but should probably be called the “internal and external edit mode” because it’s basically the same as the internal edit mode, but works for regions as well.

I’m too dumb to work out what smart mode does, which is quite ironic really because it’s the only mode mentioned here that actually is a mode. The rest are all tools.

An actual modal (and perhaps more sensible) behaviour would be to have separate modes for operating on timelines, regions, or notes/automation, and collections of tools that can work in one or more of those modes. So grab, snip, and edit could be tools that could be used in all three modes, behaving differently depending on which mode they’re in. Other tools, like timestretch, would only be available in region mode, and so on.

This provides the context and the modifiers you were talking about, and increases the utility of your toolkit.

3 Likes
#26

The grab mode selects and moves objects, according to the tooltip, but in reality it only moves regions

There is room for improvement in tooltip descriptions and different modes, that’s something I can definitely agree with.

The range mode doesn’t interact with objects in the timeline at all, but the timeline itself.

The range selection mode as implied allows you to select a range of time on the timeline. A range is not an object, it is only a period of time between two limits. I think the mode is aptly worded and described in the tooltip in the current release.

I’m too dumb to work out what smart mode does

The smart mode transitions the grab mode between range selection and region selection depending on where your cursor is positioned on a track, if it’s in the bottom half, you can grab a region, if it’s in the top half, you can select a range. Personally I’ve never found much use for this, it’s led to me making inaccurate selections which isn’t a good tradeoff for the very slight improvement to workflow it offers.

it’s basically the same as the internal edit mode

They share similar context-sensitive functionality but there is a main difference between the two, you cannot select a range of notes with the draw tool. When I’m editing instead of drawing, selection is more important to me, which is why I think having the separate editing mode is important.

An actual modal (and perhaps more sensible) behaviour would be to have separate modes for operating on timelines, regions, or notes/automation, and collections of tools that can work in one or more of those modes.

I think this would needlessly complicate workflow. On top of just selecting a mode you now need to select from several different tools to perform operations, many of which would probably be very simple and could be made available based on pointer context and modifier keys with the current mode without overloading too much, which is the way Ardour handles it now. As I said earlier, there’s definitely room for improvement, but the current modes are still well formed in my opinion.

EDIT

is quite ironic really because it’s the only mode mentioned here that actually is a mode.

If we take other modal software like vi (a text editor) as an example Ardour’s modes function in a similar way. I don’t think your statement is entirely inaccurate though, some modes are more akin to tools and I think there is a blurry line between the two because they are perhaps not as fleshed out as they could be. However, there is still a defining difference. As an example a tool in graphic manipulation software has a singular purpose, vector selection, drawing circles, rectangles, lines, etc and generally do not have multiple capabilities depending on contexts that handle different functionality. In Ardour when you use the editing or drawing mode, you can manipulate content in many different ways, and different actions and keybinds are available depending on context.

#27

As a long term user of Ardour and Mixbus*, I do like the existing shortcuts and system when working with MIDI and I like the workflow and works very fast on it. I find everything very intuitive. It seems to me that when people want to change the way things are done, it’s because they are used to do it other ways in other DAWs, so many people have different wishes on this subject.

There are however some well-known issues from a long time back, but I think that the developers are very aware of them. From what I understand from @paul, most issues can’t be fixed before the underlying timing system is rewritten and that is a 7.0 target.

I do not do the workarounds, like moving a region start a tiny bit before the regions first note, because workarounds like this kill the flow, so my approach is that I use Rosegarden for most of the MIDI, syncing both Rosegarden and Ardour/Mixbus together. When I’m done with the creative initial work, I export it as a MIDI file which then is imported to Ardour/Mixbus. From there, I do the final editing and the final MIDI stuff. So now, I’m waiting patiently for version 7 to come. Things are like they are and I’m fine with that.

1 Like
#28

All of my suggestions are meant as optional settings to customize Ardour to one’s personal workflow and liking. There are many types of users, and there is no reason to avoid things that can improve the experience for certain types of users. Argumentation that suggests “I am fine with what we have / I dislike the (optional) idea, therefore no change is needed” is nonsense. Ardour is an open project and should be inclusive, instead of exclusive in nature. And if some relatively small change or option makes the experience better for just 10 out of 1000 people, it should still be considered. Also, I’d like to mention that getting used to quirks and workflows surely results in faster workflow and after some time, being fine with it. But please also consider parts of the community / userbase that are newcomers to Ardour, as well as possibly coming from other DAWs, with established habits, workflows and muscle memory. There is no reason to leave those users behind, just because you already had a head start and got used to things the way they are. Again, I am suggestion options, not ultimate changes here.

Oh, and “things are like they are” - no. Progress, evolution, development. If we would approach software development with “things are like they are”, we would have stagnation and terrible software. Bugs? Doesn’t run at all? Doesn’t even perform the intended task? Well, things are like they are.

1 Like
#29

My suggestion to improve MIDI workflow in Ardour 7 - User Defined Menu
Question is where - just extended where it is or maybe in main menu or defined for all clicked objects

#30

Vi is the precise example I had in mind when I was describing modes. I don’t see the similarity at all.

Right, and the grab mode can only move regions, and the snip mode can only snip regions. By your own definition that makes them tools because they only have one purpose. But they’re in the same group as the modes.

Maybe this is the issue. From the point of view of an end uesr, it’s not clear to me that Ardour makes a distinction between tools and modes in the first place.

1 Like
#31

The whole MIDI editing process needs a rework :stuck_out_tongue:

3 Likes
#32

It’s also possible that you find it intuitive because you’ve become used to it. Inconsistencies in the UI that go unnoticed by seasoned users stand out like red flags to newbies. Both perspectives are valuable. The best way to improve a UI is to have a dialogue between both types of user.

So maybe the newbies have a point after all :wink:

1 Like
#33

It’s not that bad. :slight_smile:

I know I’ve found a lot to complain about at the edges but I actually quite like the midi editing feature overall. Like computer games, DAWs are in that unenviable category of software where the threshold for good enough is next to perfect.

3 Likes
#34

I believe that Ardour/Mixbus came with MIDI as late as 2015 and I have worked with all kinds of MIDI since the last half of the '80s. I can assure you that the way Ardour does MIDI was new for me when it came! :slight_smile:

But yes, the so-called newbies do very often have good points (except when they try to change the “soul” or selling points of a program). Workarounds and old habits are big enemies and make one blind or easily ignorant to problems, so I agree when you say that newbies might have a point!

So no, I do not have anything against new suggestions, especially when they are better than current stuff - and better than the ways things are done in other projects! :slight_smile:

I might not be satisfied if things have not improved after version 7 of Ardour (and probably Mixbus* 8, just guessing), but the way I see it is that they need to fix underlying problems before they can even touch many of the issues - which is totally ok and understandable for me by now.

2 Likes
#35

Oh, I couldn’t agree more. Performance and reliability of the existing features is much more important than any of the stuff I’ve brought up in this thread.

#37

Copying tracks should be more intuitive. - when you select regions on many tracks Ardour should select all tracks with selected regions

#38

I hope v7 will get rid of the remaining quirks when working with midi (stuck notes, disappearing notes).

I would love some composition tools like locking to scales, chord types, transposing in key.

4 Likes
#39

From what I’ve read, it should fix those, but I’m not one of the devs, just an avid fan. As far as locking to scales/chords, check out Unfa’s Ardour MIDI Masterclass video - some of that functionality is already in there, it’s just buried beneath a couple layers of menus and keyboard shortcuts.

#40

About the list editor, Cubase’s is conceptually and visually the best and should be copied. Then improved (it has hardly changed in 30 years and some small details could be). Given its age, I believe it is no longer copyrighted (if it ever was - no idea how computer laws work). I can post screenshots if anyone is interested.

1 Like
#41

I’m always doubtful of claims that one piece of software is “the best”. It might be the one you prefer but not what everyone will prefer. I’d rather cherry pick from a range of different software that vary in implementation.