As you probably know I’ve made a lot of videos teaching people how to use Ardour, especially for MIDI-sequenced electronic music.
MIDI in Ardour was always buggy and frustrating to work with. However after the 6.0 release things have only been getting worse.
Newly introduced problems include an incredibly destructive bug that happens when editing MIDI regions, and the user’s actions can be applied to any amount of randomly selected MIDI regions in the session, making notes longer, shorter, offsetting pitch or deleting them.
So every time you edit a MIDI region, you may be messing something up in your project, and once the session gets a little larger, it’s impossible to manually make sure that nothing was destroyed. You re lucky if a regions was copied somewhere and only one copy is affected by this bug. Sometimes all copies get mangled.
Just now I’ve been working on a new piece of music and about 1~2 hours in I have had this problem again, where an entire MIDI part (several consecutive MIDI regions) on my timeline have been wiped out:
@paul , @rgareus - please do what you can to eliminate this problem. This is the most destructive bug I have ever encountered, and it feels like Ardour hates your guts. There was something similar before that just wiped out random regions, but this is even worse.
Also - I have already reported an extremely similar problem for Ardour 6.7 around 3 months ago:
As far as reproduction steps go - I am afraid you just need to spend a few hours editing MIDI to encounter it.
Make 6~8 MIDI tracks, create regions with notes on different tracks, duplicate them, edit them, make notes longer, shorter, offset them up and down with the keyboard shortcuts. At some point (for me usually about 1-2 hours into a new project) Ardour will start applying edits to regions that you did not intend to modify. Sometimes if you spot them early you can undo your way to safety (in exchange of loosing recent work), most often you can’t.
Oh, and share you creation afterwards
When you enter the Edit mode Ardour highlights regions and notes that I am not intending to touch, Sometimes nothing happens, sometimes they get treated like actively selected notes and all my actions apply to them. Sometimes that happens out of view.
It’s hard for me to recommend Ardour for MIDI when stuff like that keeps happening, and updates seem to introduce more and worse MIDI bugs over time. I was hoping the Ardour 7 release will fix all the issues with the NuTempo branch being merged, but I am now doubting that’ll change that much - there’s much more wrong with Ardour MIDI editing than imprecise timing.
It seems to me that MIDI editing is severely undertested by the core team, and they just don’t use that part of the software at all. So it’s completely up to the users to report any issues and provide help fixing them. I’ve reported more of these bugs than I can count but it just doesn’t end.
Maybe you could figure out some automated tests with xnee or something to at least catch regressions? I don’t know, I’m not a developer…
If there’s something more I can do to help getting this (and other showstoper MIDI bugs) - please let me know.
PS: I’ve managed to more or less restore my composition - the notes had zero length so by using MIDI Transform → Set length to exactly 0.25 + trying to recover the lost note length information from memory I got to more or less where I was half an hour ago.
There’s something I won’t get back though - the creative flow.
How can I trust Ardour won’t destroy my work again in the next 5 minutes?
Every move can be the fatal one.
I could save the project in a new directory every 5 minutes or setup Btrfs snapshotting of my projects folder or rsync everything to a new subfolder to keep the MIDI regions files in case I need to restore them (also lots of manual work) spending my time trying to mitigate these bugs instead of making music…
One can’t help, but look up to Zrythm and hope it’ll let him be creative without this kind of problems.
Or go back to 5.12 because it seems to have been much more predictable with MIDI editing. Unfortunately.