Hi, I think Ardour need a better Velocity approach to edit a group or edit all the notes of a track (or chanel). The actual approach point on a individual note edit and is cool for small corrections, and group is confined to edit all in the same direction (up or down) when various notes are selected. Nice functions exists for create a curves (thanks to Unfa for demostrates this) but are insuficient and limits the workflow.
Why a velocity lane do not exists how midi CC approach?
I think the «unique window» is a valid approach but not incompatible with lanes for velocity or tempo map (associated in thethevoid normaly void Master track for default) and put ardour to next level on midi.
Really cool features come to ardour in the last years but some basic features like this are not present yet.
I think some ideas for midi, like a Curve Approach. Video editors, Animation and especially Video Compositing programs (Olive, Synfig, Blender, Natron) had a curve editor that interpolates all curve for discrete events (limited for the FPS) from only two points at the star and end of a selection! The curve is drawed in a Bezier curve form and is easy to create natural and non-linear flows, movements, animations in a couple of seconds. I think orchestral crescendi or a flexible tempo on ritardandos, etc. or any MIDI CC had in this option a more natural and incredible powerful tool for any aplications, and for any Automation lane too.
Bezier interpolation makes no sense in audio context. Ardour uses Centripetal Catmull-Rom-splines when applicable, along with logarithmic and exponential interpolation.
Hi Robin. Maybe in a fade has no sense because amplitude perception is non-linear, but I suggest this for all automation, in special for midi. In the composer side a curve has much sense for many things in a Lane for s MIDI CC or Tempo, but only ramps and continuous draw is available (except velocity), many programs have a curve approach too.
I think chords is not a good reason for delay this, every DAW have a tool for drawing velocity and is a very important thing on midi side, imagine a car without lights, this runs but only in the day. In a simultaneous notes the single note edit can apply (out of ramp or drawline), the 0005608 and related probes this is a important thing.
I can’t follow the whole discussion in the bug tracker, but would like to give my two cents here.
and there is no consensus how to handle chords
I think the question of polyphony is not so important because the main benefit of vertical velocity lanes is the editing of monophonic tracks. Besides, there is still the possibility to edit the velocity using the previous method.
You can see what I would like to do in the video at minute 0:30: Cubase Skills: Velocity & Automation Editing - YouTube
Click and drag and freehand paint a velocity curve. I know that Ardour also offers functions for some of the additional editing methods shown in the video. Again, the usability demonstrated in the video is really awesome.
But to answer the question about polyphony: Each midi note gets its own lane which all lie on top of each other. If none or all midi notes are marked, all lanes are processed relational to each other. If one or more midi notes are marked, only the marked ones are processed relationally to each other. The velocity lanes of the marked midi notes are graphically brought to the front. But as I said, I don’t think it’s that important. I don’t mind if there is only one lane for a chord with which only one fixed velocity value can be set for all midi notes (to change the velocity for individual notes you can still scroll over the note).
nobody has volunteered to implement it
Ok, this is already a real problem
What I have read so far about planned features here and there is really insane: reworked (midi) timing, step sequencer, clip launcher, scales, and so on. Vertical velocity lanes would make the whole thing really round. I do not give up hope that at some point someone will find someone to implement this
Nevertheless: Thanks to all who put time and work into this project!
Velocity lane would be very useful for editing velocity of monophonic tracks. Imho it is not meant for polyphony and therefore it does not need to take that use case into consideration.
In a typical midi song there are usually lots of monophonic tracks that would benefit from velocity lane editing. You could for example easily and quickly randomize your drums with this method. I use Ardours “randomizer” for this now but using it requires many more mouse clicks and trial and error before I get the result I want. This is because I don’t want velocity to be totally random but need to have certain beats accented.
There is a good example video for how this is done in Muse and I think the same method would be very useful in Ardour also. When the video starts you can hear the monotonous velocity of the midi drums and about 1 minute after that you can see how drum velocity is easily and quickly randomized drawing a velocity curve with the mouse:
Thanks for the reply I don’t quite understand “In that case fader automation with a post-fader synth can do the trick already”. A drum sound can have multiple audio layers (samples) that are triggered using different velocity values. This mimics the real drums that produce a different sound when the drummer hits drums soft or hard. I cant quite understand how volume automation could do the same.
I hope you can take a look at the video I posted previously. It just takes 1 minute and the use case is right there. It’s much harder to explain what we want than to see it in action. The author of the video goes on a couple of minutes editing drum velocities but it just takes 1 minute to see the usefulness of it.
How velocity changes affect the volume of the sound depends on the synth. For an Organ the velocity makes no difference while for a piano velocity usually maps to a exponential loudness scale.
If there is also an audio-stream passing through the Fader, then both Audio and MIDI data are scaled.
same as Audio using a linear coefficient. * 0 (-inf dB) … * 2 (+6 dB).
Am I missing something or do I then no longer have a fader for leveling?
In addition, the handling is very cumbersome. For example, for a 4 bar Hi Hat loop I have to copy not only the Midi region, but also the automation. For me, this workaround is unfortunately not very practical.
Here is a quick and dirty screen capture showing a possible workflow. It isn’t perfect, it is still a little clunky but some things actually could improve it significantly (Being able to copy MIDI ranges and automation together for instance like I can with audio)
The basics:
The first thing here, and while when midi editing most people already have it set, is to make sure you have snapping enabled to grid, it is what allows this to be much more viable.
You put the synth post-fader as Robin mentioned to scale Velocity data. Automate the fader to control velocity, and while I didn’t do it here you could draw in the automation with snap enabled to 1/4 notes or whatever to do it per note, I just rode the fader manually.
EDIT: I forgot to mention here, I inserted an ACE-Amplifier after the synth for volume control. This allowed me to ride volume and velocity separately and is included with Ardour, and obviously can be automated independently as well given this is Ardour.
In object mode, CTRL+Drag to copy (On MacOS at least) the region and place it elsewhere. Then use range mode, to select the automation, CTRL+C/COMMAND+C to copy, again with snap enabled you just snap to the 1/4, and paste that throughout. Again snapping makes it easy to do so on the note, but you could also use the ‘To Next Region Boundary’ shortcut (CTRL+SHIFT+Left/Right on MacOS) to jump to wherever your boundary of that loop is.
Is this a perfect workflow for what you describe? Not yet. The fact you have to COPY/PASTE the MIDI region separate from the automation at all is certainly a downside, but one that is fairly easily worked around as well.
It certainly could be improved and with methods other than a lollipop graph, but it at least is a start.
It’s not a workaround. it’s a workflow decision. Things have worked this way since Ardour 3.0.
You can use a MIDI bus for the instrument and use the Fader there, or even a subgroup bus if that’s more convenient.
But yes, if that doesn’t match your workflow, then this won’t help and be impractical.
Thank you for the detailed description. That’s more or less how I imagined it. It is good that there is this possibility of velocity automation - here I have learned something again. But as you also said, there is still a lot that can be improved.
The problem with the proposed workflow is, if you work on midi velocity you want to see the new values after edit, if you create a fader automation you control the output but don’t see the values (monitoring it’s posible on playback but playback only for see a region values is not reasonable).
Other problem is, an output from a score editor can be for default 64 for mf, another 80 (lilypond and musescore in fact manage this values) and anoter 75, fader for default in a non linear perspective is in 0 db close to top of fader, no midle, no in the same point in a linear velocity, then if is a 64 value another 63 values is above in a small space, and 64 values below in a big space, if you need more control on top values you need to move before automation the fader down? to middle? It’s no intuitive for new users coming from another software, in fact, fader automation for velocity control is not intuitive…
Maybe for me is a partial solution, downside on see the values is a important thing that delays any workflow, but is not the same reasons exposed before (volunteer and no consensous) polyphony is not a relevant desition because any software have the same problem, and in midi side this is the most important thing to add, most important than a clip method like Ableton or Bitwig for example.
I want to remind participants in this discussion that we strongly disapprove of the use of the term “intuitive” in this context. Saying “isn’t the same way that sofware X, Y and Z do it” is fine.
I don’t quite understand “In that case fader automation with a post-fader synth can do the trick already”. A drum sound can have multiple audio layers (samples) that are triggered using different velocity values. This mimics the real drums that produce a different sound when the drummer hits drums soft or hard. I cant quite understand how volume automation could do the same.