It sounds like what you really want it persistent dialog settings across sessions. More dialogs than that could make a use of it.
As someone who was 100% used to a separate midi window as I came from FL Studio, Ardourâs approach seemed mad to me initially.
But as with most things, once I learnt some shortcuts it was just fine.
1 Like
I am OK with the current way Ardour in-window MIDI editing approach. But one thing I miss is the bar graphs to edit velocities that separate MIDI windows often have, like in Muse. It makes editing velocities much quicker by simply drawing with the mouse (and fine tuning later)! I wonder if something similar is possible with the current in-window editing approach.
Another useful feature, which I assume is impossible in the current setting, is to edit, for percussion tracks, the position of the MIDI notes/instruments on the âpianoâ on the the left. In Muse, when I edit a percussion track, I can enter the name of the particular instrument in the corresponding MIDI note, which helps visualize what each notes plays (kick, snare, hihat, etc.). But, even better, I can reorder these instruments, so I can have, say, all toms together, all cymbals, etc. Thatâs quite useful! But, it is not nearly as important to me as the MIDI velocity editing I mention above.
For now, I often do MIDI programing in Muse, then import the MIDI file to Ardour. I often do a lot of editing in Ardour too, though.
2 Likes
This is well known to the developers it has been discussed in Mantis (by myself and many others) and on IRC many times. âEnergyXTâ an ancient DAW with a half-assed Linux port did in-window MIDI editing wonderfully (and still does) and pretty much every established DAW has vertical velocity bars and there are a wealth of examples to study. I honestly have never understood the reticence to implement this, it seems to be one of the first things you would implement in a MIDI sequencer not one of the very lastâŚ?
2 Likes
The bar graph is a nice thing, but itâs a nice trick you can do thatâs way faster in Ardour (at least in my experience) than moving the mouse to the graph bar and drag the velocity: In EDIT mode, hold down the Alt key while scrolling with the mouse wheel. That will change the velocity on selected notes in steps of 10.
1 Like
That is a nice feature, indeed, but works well for individual notes or selected notes to which you want to apply the same change. But drawing with the bar graph, I can draw a whole curve for a sequence of notes (setting different notes at different velocities) much faster.
1 Like
Canât draw a crescendo that way
2 Likes
Fader automation? If the fader is before the synth fader automation controls the velocity. If the fader is needed after the synth, a velocity plugin might work or maybe easier, use a midi channel into an audio channel or bus. Use the midi channel to control the midi velocity and the audio channel for audio fade. I suspect it would not be too hard to create a MIDI velocity fader plugin that could then be automated for things like crescendo. It is too bad velocity is not listed already among the automation lanes.
Velocity canât be automated like that. Velocity is part of the MIDI note on message itâs not continuous.
Think about that for a minute.
digital audio is not continuous either. The fader applies some math to each sample. There is no reason that a fader or automation lane cannot apply some math to each noteâs velocity value. The fader would not hard set the velocity but rather multiply velocity by some amount. A velocity plugin could do either. It is not really any different in effect than "dragging the mouse across the âlollypopsâ. The main difference is that with the lollypops the crescendo is hard baked into the midi data itself and with a plugin, it gets added every time while live. (destructive vs: non-destructive) so the crescendo can be changed as many times as you like without changing the input file. I would think that would be better for something like a crescendo but not so good for correcting individual notes.
I want it in the MIDI data so I can tranfer it between programs.
1 Like
That is the same for MIDI controllers then (CCs) which are all automation. So what you are looking for is a âfreeze automationâ or âfreeze midi automationâ (does bounce with with processing do this if there is no synth?{synth could be in a bus}) Ardour, like most any other DAW, is not built with the expectation that the file will be processed elsewhere but it is certainly true that some people want to work on a score and others are used to whatever midi editor they used first (and what they therefore call âintuitiveâ).
In any case, an automation lane for velocity would seem to me to be more in keeping with the current workflow of the rest of Ardour. The ability to freeze all midi data into the midi stream also makes sense and could be (except for velocity) the default as it could also be separated on reloading. For velocity fading it would almost make more sense to assign an unused CC to that. The saved midi would have the processed velocity so it showed up in other programs and the CC would have the value needed to get the original back. (probably not well thought out just off the top of my head) Freeze would remove the extra CC info.
There are really two workflows where velocity editing might be used (that come to mind). overall velocity changes are best done with an automation lane. individual velocity corrections for when the piano player was hamfisted. These are really two kinds of operations requiring two methods of changing I think. I donât think lollipop or automation lanes deal well with single note correction, especially with chords.
That is not a bad idea, and I think it might work in many cases.
But another problem with that (besides not being part of the MIDI track itself) is when one wants to adjust velocities of different notes played at the same time. If I am editing drums, snare/hihat and kick/hihat are often played (almost) together. I can select the notes of one (kick or hihat, say) draw a curve for those and then do the same with the other (drawing likely a different curve) in Muse. I cannot do that with automation.
1 Like
That smells like a workaround not a standardized industry-wide workflow⌠
2 Likes
How would such an automation lane handle chords? How about we use the velocity system the way it was designed in the 80s instead of trying to find cumbersome workarounds?
1 Like
In such a case, you are treating each note (as in frequency) as a separate track. Really the same would apply here. split the drums into different tracks and automate each. Certainly if one was recording live drums each mic goes to a track.
Thatâs ridiculous. With your system if I play 6 notes at the same time I need 6 automation lanes to control the velocity. If I have a whole orchestra going thatâs going to be hundreds of automation lanes. No thanks.
2 Likes
In the time that has been spent on repeatedly answering why this issue has not been implemented and the numerous esoteric discussions why not to do it on IRC and posting on Mantis why the requesterâs reasons havenât been quite compelling enough to just include it AND the pleases nobody (hyperbole alert) implementation of the horizontal velocity lines inside the MIDI notes couldnât it just have been implemented in a normal wayâŚ? 
There are indeed things to be maverick about⌠and then there are things that just make senseâŚ
3 Likes
That previous post needs a shade alert, because it casts so much shade I though there was an eclipse.
Also, as someone who edited velocities for every note on 10 drum tracks on an album to make it sound human, that would have been much easier if there had been a dedicated velocity window for editing the MIDI data - like instead of 20 minutes per 16 bar region, it would have been 2.
1 Like
it is a workaround⌠at least using the bounce part is. (it crashes Ardour BTW) However, for times when a âcurveâ or line of velocity change is required, the automation lane does make sense. Being able to fix that change or use it non-destructively could be useful too.
perfectly? if using it to do a crescendo it would do what was expected. note that I did say individual note edits would need another method. There are two use cases. it started with us talking about âswipingâ lolipops to make a crescendo. That is an automation lane style of edit. Fixing one note in a chord is obviously a different workflow that lolipops would also have difficulty with.
Ardour does need a better way of setting individual velocity. I would expect a box that lists note, start, end and velocity⌠mouse over any one of them and scroll.