Some observations on MIDI editing in Ardour

I’ve been making a MIDI mockup with Ardour over the last few days. This is the first time I’ve really done any significant MIDI work in Ardour, I usually just do audio stuff. I’ve found that MIDI editing has vastly improved since the last time I tried it out a few years ago. However there are still some workflow and UX issues and I think I’ll be going back to Qtractor for MIDI editing for now.

Here are the issues I ran into/ suggestions for improvements.

I couldn’t find an option to set middle C to C3 on the piano roll keyboard

Automation/velocity editing is glitchy, sometimes I’ll select a bunch of notes and click and drag on a velocity lolly pop to move them all up or down, but just a couple of them jump to where I click instead.

The automation point handles are tiny, it would be nice if these were larger, more on the size of the velocity lolly pops.

More MIDI specific colour preferences - it’s very difficult to make the piano roll colours usable in all tool modes, and because a lot of the colour settings are generic, changing them for use with MIDI makes them less ideal for audio.

Randomize options should be ± % from current value. This is a must. I don’t know why I would want to randomize the position of the note to be between the beginning of the region and the end of the region. It should be a shift from the note’s current position, this goes for velocity too, and any other automation data that can be randomized.

No ghost track - seeing the notes of another track behind the MIDI you’re working on is very helpful, especially when working with complex arrangements.

Scroll wheel shouldn’t affect velocity of notes unless the mouse is over the note. I kept moving my scroll wheel to scroll up and down the page only to find it was changing the velocity of some note I had selected but that wasn’t in the visible area. If there is a way to disable scroll wheel affecting velocity altogether then I’ll use that - but I didn’t see that option.

Need quick way to open and close track to fill the screen, accounting for visible automation/velocity lanes. It’s very cumbersome to close up one track and then open another, and then switch to another, etc. There needs to be a 1 key shortcut to open a track and close a track, and expand it to fill the viewport.

Can’t move automation points with MIDI notes - very few DAWs have this for some reason and I think it’s critical. If I record some notes along with automation in real time and afterwards I want to shift those notes on the timeline, I need the automation data to go with them.

The only free DAW I’ve found that can do this is Qtractor, and even there it’s a little clunky. I think this should be something that is toggled with a modifier key because there are occasions when you don’t want to move the automation data with the notes.

Peek 2024-08-02 11-16

8 Likes

That would really be nice indeed!

Yes, I agree. I’ve experienced the same.

One thing that would be a big jump in productivity (for me only?) would be having control over the default position of the playhead.
When editing midinotes, I’m allways editing on the right side of the playhead, not on the left. So it would be logical that the playhead is always on the left side of the screen. But when zooming in and out or if it crosses the edge of the screen it jumps back to the middle when playing stops. So you end up dragging the track in the summary back to the left (or tired of dragging all the time, give in and edit only on the right half of the screen).
This is not new. A couple of years ago someone mentioned this also and came with this idea of having a setting in the preferences. So you can set the default position of the playhead to the position you want instead of the middle of the screen.

And if this bug could be solved that would be great.
Consolidating midi-regions is something basic. I do it all the time. But when tempo changes are present in the project it doesn’t work. It messes things up.

https://tracker.ardour.org/view.php?id=8887

There is an on-screen dropdown for the zoom focus, which is what a zoom is “centered on”.

There are several options, including the playhead, the mouse, and the right and left edges, the center, and “edit point” which is separately controlled.

It also sounds as if you have auto-return enabled, which you either want or do not want. If you want it on, then naturally the playhead will jump back at transport stop.

Yes I tried all that to find some sort of controlled behaviour. The problem is probably that it’s the combination of zooming in and out and the Follow Playhead and Auto-return on.
The point with midi editing is that it’s: editing-start-listening-stop-editing-start-listening-stop etc, etc concentrated on one or a couple of measures to get them right. So yes, auto-return is on but if transport stop defaults to putting the playhead in the middle of the screen, that’s my point. And I haven’t found a way to have it on the left and keep it there.

Maybe it boils down to this. The jumping back position.
Most of the time it jumps back to the middle of the screen. But suprisingly approximately one out of three or four it jumps back to a third of the screen when stopped at the same moment (!!??). It’s unpredictable.
I’ll try with a clean testsession tomorrow.

Try with SHIFT+F (I can’t remember how is the command exactly named), then zoom in the zone you need (with the playhead at the left of screen).
Do your edits.
When you go “editing-start-listening-stop” you should be back to the initial situation, IIUC.

HTH

Hi Piergi

Shift + F is Stationary Playhead. Return of the playhead is even more unpredictable. It returns to the initial bar where it was but that bar could be anywhere, depends on when you press stop and if this bar is off the screen that bar/playhead position will also default to the middle of the screen. Not the initial situation.

Closest to a workable situation is:
Zoom Focus set on Left
Placing the Playhead on the left
If I manage to let the playhead not go over the edge of the screen when I press stop it returns to the left. And that’s ok. Zoom in and out keeps the playhead on the left too.

But the way I’m editing is a lot of switching between zoom-levels and almost always involves the playhead to go to the next screen and therefore at stop it’s back in the middle.

Just took a look at how Reaper handles CCs and Midi notes. It seems by default they move together.

Peek 2024-08-10 17-51

For MPE, this makes perfect sense to me.

But I confess that in the more general case it does not. Look at your example. As you drag leftwards (creating a chord with the 3 upper notes), those notes are also subject to the CC data that moves with the leftmost (longer) dragging note. I don’t see a reason why this would be obviously correct.

I do agree that it ought to be an option, somehow.

EDIT: watching more carefully, it looks to me as though Reaper is doing MPE-style editing even in a non-MPE case … ie. the CC data that is temporarilly coincident with a note duration becomes considered to be a part of the note. MPE makes this unambiguous, but without MPE, chords make this sort of association hard to do “right”. Suppose you move one note out of a chord where is CC data present? Does the CC data move or note? Is it duplicated with the moved note?

Yes, actually I would probably never have a reason to do this in a real project. I was just testing to see how the feature worked in Reaper.

My use case is mostly for monophonic instruments, but I could also see it being useful in polyphonic situations such as double/triple stops on strings, and with synth patches.

It moves the CC data, I’m not sure if that is the best approach, maybe copying it would be better. Also if you delete the note it deletes the CC data. I also found that holding shift+alt will select all the notes in the chord, which is handy :slight_smile:

Peek 2024-08-10 21-28

Ran into a glitch CC editing example, though I’d share - no idea what’s causing it, snapping on/off makes no difference.

Peek 2024-08-11 16-44

Edit: Seems to be caused by having one midi region on top of another. I recorded over an existing region, in an area with no MIDI data. I usually do this and then combine the regions.

although GIFs are sometimes cool, sometimes with no voice over it is hard to divine what you’re trying to do and what you expect vs. what happens. Could you expand a bit on that?

Yeah so I had two MIDI regions, one above the other and I was moving the CC data associated with the top one and it kept jumping to the left, as showing in the gif. Once I moved the top region away from the bottom one, so they were no longer stacked, the issue went away.

I’ve since tried to recreate this as an isolated test case but can’t get it to happen again. If I run into it again I’ll try and isolate it and provide an example.

Which version of Ardour are you using?

I fixed a bug a that could lead to automation jumping backwards in time a few weeks ago in 8.6-310-g5a647cd84a – hard to say if that’s what’s shown in the .gif though.

I’m using nightly build 8.6.393

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