My Ardour MIDI rant

Hold your horses. Editing means also inputting midi data with the mouse. This is an important workflow for creating midi drum tracks and works fine in Ardour. There is no reason to remove it.

1 Like

Same reason why you don’t usually wet record audio. You can tweak the sound of the synth, or replace it, or further automation the synth.

This was in response to the suggestion to remove MIDI [tracks] altogether, so I thought to give the idea a spin. There may be convincing arguments, and perhaps even some novel approaches to be found.

Say, editing MIDI is time consuming anyway, and Composers prefer scoring tools. This leaves

  • musicians playing MIDI live on stage
  • users recording a master-keyboard, and are only arranging things
  • the pattern crowd, most of which rather use plugins for those (e.g. AD2, numerology,… or BSeq) and synchronize those to the global timeline.

Those could be done with non-destructive editing, which is more in style of a DAW anyway.

Thanks. I am going to try and minimize the chance of it happening myself, and eagerly wait for 7.0 :smiley:

This is something I’ve seen pretty much always. I have probably reported it at some point, but I got so used to it I may have forgotten to do that.

Well, I would really not want to have MIDI editing gone from Ardour. It’s flawed, but it’s working for me regardless. Honestly I wouldn’t be able to my daily job without it.

I hope the 7.0 fixes will open a way to getting MIDI on par with audio.

I do think that nowadays a DAW is expected to have both audio and MIDI capabilities, as an artist really can’t do much with modern music without one or the other…

I think that - killing off MIDI would really, really hurt Ardour. And also waste a huge potential and bulk of work that has been done on it.

I haven’t made my rant video to inspire dropping MIDI from Ardour - I wanted to inspire fixing it!


I will echo some and say, please, please do not drop MIDI editing.

I can see the problems with MIDI in Ardour, which in fact led me to to all (well, most) MIDI programming with Muse. But I often times need some edits while recording, and being able to do it directly in Ardour is quite helpful. Tempo ramping is also very useful!

The developers are aware of the problems with MIDI and already made clear that the fix is not simple. It will take time. This is understandable and I’m just happy that they are planning to address it and it is part of their roadmap. Of course, I also would like to have it right now, but I cannot put my coding skills where my mouth is. (Can anyone?)

I look forward to a better implementation of MIDI in Ardour!


tl;dr: MIDI implies several workflows that currently Ardour tries to solve with one MIDI track type that offers a huge flexibility. Maybe, we could have more feature limited MIDI track types, but more specialied in every workflow.

So, considering these use cases that @x42 pointed out:

Say, editing MIDI is time consuming anyway, and Composers prefer scoring tools. This leaves

I agree, doing that with Ardour is very time consuming. Scoring tools offer a better overview in the musical domain, and I would say that music notation is the preferred language over grid/piano roll notation in that scenario. However, I think there is a workflow in the half-way, which is using a scoring tool with Ardour sync’d with JACK. So, in that session/composition/recording you can also use audio. I have used Ardour sometimes that way with MuseScore, and it partially works, but there are several drawbacks that makes the process a bit annoying:

  1. If I record the MuseScore’s MIDI output to an Ardour’s MIDI track, the beats are not sync’d, they arrive later in time. I do not know if it is an issue of JACK not properly notifying port’s latency, or MuseScore not setting it, or Ardour not reading/compensating it.
  2. So, exporting to MIDI in MuseScore and importing on Ardour would solve that. That makes the workflow much more slower, and you cannot do some proofs to test this or that change so quickly. I see that a good option when you have finished the score work, and you want to record the audio. But might be that is not the proper order in the recording process.
  3. When Ardour rolls the playhead, MuseScore decides to get the focus, which can bother some people, specially in a one monitor setup.
  4. Things like tempo ramps do not work. AFAIK, JACK does not do provide that mechanism, so both programs will not able to do that. This might affect the export/import approach, because every program might interpret the tempo ramp in a different way and beats could not match.
  • musicians playing MIDI live on stage

I have not used this, but I think it can work quite perfectly. I see a bit tricky how to switch between plugins or patches. But I guess you can have several MIDI tracks with different plugins, and filter by MIDI channel, so, in the MIDI controller you only have to switch the channel.

  • users recording a master-keyboard, and are only arranging things

This is also doable, although arranging is a bit tedious, but you can do some small adjustments here and there.

  • the pattern crowd, most of which rather use plugins for those (e.g. AD2, numerology,… or BSeq) and synchronize those to the global timeline.

I haven’t used that kind of plugins, but they could be more specialized for doing that work. So, it’s understandable that people prefer it.

So, in my opinion, the current MIDI track cannot fully solve all possible use cases. And, in a way or another, users might find some limitations in every scenario.

Maybe that’s the problem, and here is my proposal. Having several types of MIDI tracks, and limit what they can do according to the use cases:

  • Current MIDI track: intended for recording and minimal editing: arranging some notes, quantization, etc.
  • Live MIDI track: maybe add some features for switching plugins/patches easily, maybe involve some Lua-specific scripts for observe pad triggers, etc.? I do not have specific ideas about how to improve this workflow.
  • Pattern/beat box MIDI track: You can create patterns in an “pattern editor”, so you edit a set of patterns, not necessarily with the same length (1/2 bar, 1 bar, 2 bars, etc.), and you have to manage to put them in the timeline to build your track, like using block pieces. This type does not have an input (cannot be recorded), but it only can be edited in the interface.
  • Score MIDI track: some basic musical notation features. Of course, not at the level of MuseScore, but it could start as a proof of concept, and let’s see how it evolves by adding the more requested/needed features. Like previous one, this cannot be recorded, but only edited through the interface.

Bonus tool: convert from one type to another. That might work with some quantization process, but it would probably result in ugly results and/or wrong/non-sensical conversions, as usually happens with human interpretations when are opened with notation software :smiley:

Disclaimer: I am aware that this is a huge amount of work, and I am not related with Ardour’s code base, so my estimation will probably still be insufficient. Also, I am sure I ignore some architectural designs that would be prevent to implement any feature as I have described it. However, I am open to discuss this approach, and I would like to contribute by coding it, if developers and users think this might be a good approach.

I honestly think you misunderstood @GMaq. He was saying via a rhetorical binary opposition to either remove it completely (obviously not) or make it more like—or better than—the “industry standard” (yes, please!). I read it as a plea for the latter not the former…

I’m really not detecting any bitter tone in this thread. @unfa’s “rant” video was the least ranty “rant” video I’ve ever seen. He has a great way of being entertaining while getting his point across. I’d say the majority of the thread is a plea for more advanced MIDI operation. The developers have thick skins (I hope) and can see any suggestions/criticisms about MIDI as coming from a love of Ardour.


@bachstudies @x42

Yes this is absolutely correct, I would not want to see it disappear at all (just improve :wink:). Thank you @bachstudies for your keen sense of rhetorical binary opposition… :grinning:


(Do not take seriously) just a Cry from the heart))))
Why LMMS devs didn’t contribute any MIDI skills in to ardour///? Could be so cool if some part of LMMS become a part of Ardour (added sample side bar with pre-listening, add a vertical stick velocity track to midi).

Or this feature could be so good:

QTractor has some good MIDI features, but it has no so great routing features like Ardour has. Musescore has a score… Hydrogen has a drum sampler… Linux has so many separate open source tasty sweets… If Ardour could join them together////

Dragging plugin’s automation with midi regions - also a super dreamed feature))


This is one of those funny things; Yes, there are definitely flaws in midi editing in Ardour 5, and some left in Ardour 6.

Despite those, I have done intense midi sessions in both versions, and for me it really does not get in the way of my creativity. Especially true for version 6.

So yeah, I’m looking forward to the improvements coming in future versions. Until then, I’ll continue making heavily midi based music happily in Ardour 6.


They’re not empty. Just look empty.
Manually resize the offending track a pixel or so and the notes are redrawn.

FWIW I haven’t had this problem since the new version. So YMMV.
There are some other drawing issues though, when moving the cursor over the notes. Not sure how to describe it yet to make an understandable bug report.

Check if your issue is the same as this and add your observations to the bug report:

1 Like

5 years and at least two full-time developers to get to a useable state :slight_smile:

May I interest you in upgrading to v6 so that you could actually use what was proposed in that video? :slight_smile:

I think I don’t understand you question clear…) Do you mean this feature is already implemented into v6? (Didn’t know/that could be super:)) I’ve uploaded the link to this video as an example of how the vertical velocity sticks could be inserted into the midi track (very cool to have a possibility to open it in the same way as an automation track)

The note velocity marker inside notes is in v6 already :slight_smile:

Unfa, you told about a piano-roll window. My opinion is that there is no need of separate window, because of need of zoom anyway. When you open a piano-roll window, you’ll need to focus at some little parts of midi event. So you can just zoom a selected midi event directly in the main editor. Opening the separate window is just a redundant operation. I am for an editing in the main editor )) “G”&“D”&“E”-modes are great IMO!! Just may be little improvements and user technics of focusing//

1 Like

Alexandre, do you mean horizontal lines inside notes?

Vertical velocity sticks let the user get the needed value just for one click (if such function implemented). As I found to correct the velocity in v6 we use scrolling, which is not critical, but not so quick as it could be, especially when you make massive corrections.

1 Like

Yep, that’s what I mean :slight_smile:

For electronic bit-boxing&synth music the main problem for me is copying/moving pie of midi stuff and automation from one part of session to another. It’s very difficult to select them all (need to select automation headers additionally as you know) and after Ctrl+X. Ctrl+C&Ctrl+V.
But for composition of melodies Ardour is rather comfortable for me: basic functions of copying/moving/transposing/etc notes and regions - are good.
The main thing is a good mode of Robin and Paul! :slight_smile: Thank you guys! Do the best what you want the most!)) But if (by chance) youi’ll get the mode to make some midi stuff - personally me will be super glad and greatful!))) And, I think, Unfa has the same ardour)).

1 Like