|Anonymous | Login | Signup for a new account||2018-05-26 16:35 PDT|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005608||ardour||features||public||2013-07-21 08:55||2018-05-18 04:13|
|Target Version||Fixed in Version|
|Summary||0005608: Velocity track idea|
|Description||The one midi feature which is currently lacking is the lack of proper velocity editing. Unless there's something i'm unaware of, the only current way is to edit individual note velocity, or groups of notes together. The only visual way of telling the velocities of multiple notes is via colour intensity.|
One solution to this, and without bringing a whole new window into the equation, would be to make use of an automation track to edit note velocities. I have included a mock up, influenced by qtractors velocity editing.
|Tags||No tags attached.|
|Attached Files|| velocity track.png [^] (137,658 bytes) 2013-07-21 08:55
Ardour_MIDI_Velocity_channel.png [^] (31,833 bytes) 2014-12-23 18:08
|Do you have any idea how that can work with polyphony, as well?|
|I never thought about that. It was just an idea i had that i thought I'd throw out there. Thinking about it now, i see what you mean. Automation tracks only works on one parameter at a time. So there's no way it could work with an automation track without a lot of work? Is it feasible at all or are there any other thoughts about velocity editing at the moment?|
its not a problem with automation track limits per se.
its a problem with conditions that involve chords. how do you edit the velocity of just one of the notes?
|i suspect lines, not bar charts, will be the likely solution to this, btw. doesn't fully solve the polyphony design problem, but it would allow editing once it was clear what line affected which notes.|
edited on: 2013-07-23 04:06
So the issue isn't a technical one regarding polyphony on an automation track? It's to do with how it would be visually implemented? Other daws allow you to select the note with your mouse to bring it's velocity bar to the top so you can edit it, if there are multiple event notes at the same time. Would something similar not work? Or have I misunderstood?
|Good editors I've seen have a circle for each note, which can be moved up or down. You could do the same thing with a line that goes out horizontally to the end of the note.|
|Bars suck. If all we really need is the ability to edit in ramps and so on, seems we can add that easily enough without a clunky bar thing that's confusing as soon as any polyphony is around.|
UI proposal: designed to fit with the current automation UI design.
The example doesn't include chords, but you can see how it would work for them. Just the red squares are draggable. The green lines are just indicators. If notes are selected in the actual track, then those notes are brought to the top of the stack in the velocity channel, thus allowing chord notes to be velocity-edited independently (if the chord has the same velocity on all notes, just select one note in the track, edit the velocity, select another note, repeat, etc.). If multiple notes are selected in the track, moving one of them in the velocity editor should move all of them.
edited on: 2014-12-23 18:53
Love this idea for 3 another reasons:
1- It helps a lot to visualize the timing of the notes.
I often have this problem when editing piano notes. e.g. there are 4 notes that are supposed to be at equal distance from each other, but not really on the tempo because plenty of emotion... and something sounds wrong in their timing but I can't hear where because they are too fast or too subtle... It helps a lot to see them on a horizontal timeline. Problems become obvious this way.
2- Currently, when scrolling for velocity, each step of scroll is an Undo/Redo action... So you have to undo 8 times to put back your 48 to the 40 it was before you scroll.
Of course this issue could be fixed another way.
3. We could get rid of the Alt+Scroll x10 velocity that is very confusing because of the Alt+Scroll for vertical zoom (which is fantastic). I bet nobody knows about this anyway, or they discovered it by mistake when trying to Y-zoom.
This way, we could simply click for large velocity steps.
? The notes *are* on a horizontal timeline. How does a velocity thing make any difference there?
I'm not fundamentally opposed to a separate velocity thing, but it's a massive mount of work completely unlike anything else we currently have for little to no mentioned benefit. I'd rather see a list of exactly what things users need to accomplish that we can't currently do (e.g. ramp up velocity from here to there) than "hey let's just blindly make a bar thing because some other programs do"...
e.g. it seems to me that a velocity tool that lets you edit the velocity of notes in linear ways might be (almost) universally superior. Perhaps we should have a bar thingie, and the benefits outweight the polyphony problems. So, what benefits?
In other words: justify with something other than "program X did it". If "we" are going to do a ton of work on velocity editing, it might as well be thought out properly first...
I am also interested in these questions because making the on-note velocity editing more powerful is something that is *way* more feasible to do relatively shortly than implementing this, and would be good regardless of whether or not we eventually have a bar thing.
@drobilla, I don't know about the priority, there are definitely some bugs that I would consider more urgent than this. #6055 e.g. or the fact that Ardour does not send any NoteOff in record mode. (I need to create a report for this)
But my point 1- above is clearly important. Let me show you why a horizontal view is important, what it is, and what it's not...
In this example, how do you know that the 4 piano notes following my playhead are rhythmically at equal distance from each other?
It's a piano part, not a drum, so it's not supposed to be exactly on a beat, it's just supposed to make sense emotionally.
In this example, I can hear something wrong in the timing of these notes but I can't explain it. If I could visualize these notes with vertical bars next to each other, the problem would become obvious.
In other words, with vertical bars, the visualization of the notes timing (X) is not disturbed by their frequency (Y).
Having velocity bars would help a lot to visualize the rhythmical side of the music.
I don't care what other programs use.
How urgent is it? I don't know, you judge...
I still think this x10 velocity steps with Alt+Scroll should already disappear.
A quick solution that would work in the mean-time would be to <Modifier>+Drag changes the velocity of a note. Scrollwheel is not very precise, and it also doesn't easily let you define multiple scrolls as one event (as opposed to click and release).
But, there are good reasons that a height-based visualisation (not bars - I wouldn't describe my UI design as bars). For one, human colour perception is not that accurate - we don't really have a way of estimating the absolute value of something from the luminosity/saturation, as with the current colour scheme. You *might* be able to improve that by adding a hue change with velocity too (e.g. red->white->blue). We're better at comparing relative colours, but I don't think many people have the ability to easily tell the difference between a note at 65 velocity and one at 70 (in the current color scheme, but it's not going to be easy in any colour scheme), but that can make a big difference, depending on the synth/sampler.
The fundamental problem is that you're trying to show 3 variables (time, pitch, velocity) in 2 dimensions. There are lots of visual variables you could use (e.g. http://jcsites.juniata.edu/faculty/rhodes/ida/images/Figure_6_8.jpg [^] ), but size and colour are probably the only ones that might work in this situation, and size also has problems (like overlapping).
Adding a velocity bar allows you to have two correlated plots of 2 variables each. It's a pretty concise way of displaying and allowing manipulation of the information, without having too much complexity (you could make it 3D, and it'd work, but it'd get visually confusing :D ). If you add a height-guide grid behind the plot (e.g. every 32 velocity, or something), then you get *really good* absolute and relative velocity estimation.
edited on: 2014-12-25 17:21
Scroll is VERY precise (and very handy) One scroll step is 1 step of velocity.
Velocity upon scroll is IMO the best idea Ardour ever had... unless you have a crappy mouse.
|I think Velocity TRACK is a GREAT idea to edit velocity|
I think the goal is to achieve easy "fader rides" for crescendos etc. I propose the second mockup be approached but on a mouse drag to change velocities, apply it to all notes of the chord the same way the fader does on a midi track (scale all notes by the same factor). You can scale the highest velocity note to the new velocity or have the behavior in the preferences (highest velocity note, highest pitch note, lowest etc). Basically automating the gain fader from the mixer but applying the effect to each note event.
If an individual note is clicked and dragged in the "velocity track" it changes velocity, but you can also do quick shaping of the overall dynamics a passage through a mouse drag. Perhaps there is a better way than an extra track or bar to achieve this, but I think this is a pretty reasonable definition of the behavior for chords. I would sure appreciate a change to quickly shape drum pattern dynamics the same way I used to do in hydrogen (which does a velocity bar for whichever drum/note is currently selected).
edited on: 2017-02-25 16:42
*Added note from IRC discussion on Feb.25/2017
In asking about the status of this feature on IRC it was suggested that a barrier to integrating this feature was how to handle 'chords' on the MIDI timeline (or multiple notes in the same vertical timeline grid axis). In my experience with other DAW's it occurred to me that visual MIDI velocity editing where the velocity is represented by a vertical 'bar' is often handled by selecting only one group of notes at a time on the same horizontal key/note path. Below are 2 examples from screenshots:
Example 1: http://bandshed.net/images/screenshots/H2.png [^]
Example one is a screenshot of the Hydrogen Drum Machine, as you can see in it's editor window keys/notes (or drumkit pieces) can be selected on the left hand side which highlights the horizontal grid axis and exposes the vertical visual 'bars' to change the velocity of ONLY the notes on that grid axis (or note key). This allows individual adjustment of only single notes at a time without affecting note velocities on other note keys.
Example 2: http://bandshed.net/images/screenshots/EnergyXT.png [^]
Example two is a screenshot of EnergyXT which incidentally also shares the ideology of MIDI within a timeline track like Ardour. EnergyXT does not allow selecting note keys on it's MIDI keyboard on the left like Hydrogen does however if multiple notes are 'drag-selected' then their velocity bars appear in the 'Velocity' lane under the grid. This also allows selection of individual notes on the same horizontal grid axis without changing the velocity of other notes.
This is how 2 other Linux grid-based editors handle visual velocity editing of notes, there are more examples like Seq24...
Perhaps the addition of a new MIDI type or class of track (ie MIDI-Drum track) could incorporate the suggested visual velocity drawing features without modifying or making changes to the existing scroll wheel features in Ardours existing MIDI tracks. In my own workflow and discussion with users it seems this kind of in-depth visual velocity note editing is most often employed in drum and percussion MIDI tracks.
PLEASE consider adding this feature as it is present in almost every other MIDI-capable DAW on every platform and is very much a standard and expected method of drum sequencing, I don't think this is a feature Ardour/Mixbus should be without.
Thanks for reading,
|I would like to add that in order for the velocity track/lane to be really useful, it's should be possible to drag a line across several events to adjust the velocity.|
edited on: 2017-02-26 12:46
Good point! Most DAW's employing vertical bars also allow to draw ramps and curves across the velocity 'bars', so this would be desirable as well.
Added Example 3: http://bandshed.net/images/screenshots/ReaperMIDI.png [^]
This example is showing Reaper (Native Linux Version) and it actually combines the features shown above, so a note/key remains highlighted (in pink) and notes shown across that horizontal axis can then be edited without affecting other notes. Actually the Reaper editor is quite full-featured and also shows the numerical velocity values on the drawn note displayed on the grid as well as handling velocity bars of chords in different colors depending on the note selected.
edited on: 2018-04-18 23:14
I think an in-region MIDI layering system could be used to show additional information for MIDI notes. Data displayed could be selected (flags?) in a layer menu- which would show a graphical, editable overlay. (editing dependent on style and sort of data)
Such overlays could be velocity lines drawn into the notes- and paired with Color, (and a Velocity Track) could make editing of MIDI velocities clearer- and easier for the end user.
The development of a MIDI overlay system, could also be the first step to enable other data that is relevant per note (such as MPE data) to be displayed. A user could choose to enable velocity / pressure / bend etc... all at once (different color automation?) or only one at a time.
Alternatively MPE data may only be shown per selected note, however having an overview of all events that occur in a MIDI region is very powerful, and allows fast editing.
To speed up editing velocity information, it may be necessary to have a dedicated Velocity tool, allows the user to left-click onto a note, and drag while holding down the left-button, to change the velocity.
A few mockups (painted on with Krita - not accurate):
MIDI Velocity in Note:
MIDI MPE Data in Note:
|2013-07-21 08:55||Leatuspenguin||New Issue|
|2013-07-21 08:55||Leatuspenguin||File Added: velocity track.png|
|2013-07-21 09:46||x42||Note Added: 0015150|
|2013-07-21 10:44||Leatuspenguin||Note Added: 0015151|
|2013-07-22 19:46||paul||Note Added: 0015158|
|2013-07-22 19:48||paul||Note Added: 0015159|
|2013-07-22 23:58||Leatuspenguin||Note Added: 0015164|
|2013-07-23 04:06||Leatuspenguin||Note Edited: 0015164|
|2014-01-22 04:23||x42||Relationship added||related to 0004324|
|2014-12-23 06:10||naught101||Note Added: 0016075|
|2014-12-23 11:27||drobilla||Note Added: 0016080|
|2014-12-23 18:08||naught101||File Added: Ardour_MIDI_Velocity_channel.png|
|2014-12-23 18:08||naught101||Note Added: 0016081|
|2014-12-23 18:52||florianb||Note Added: 0016085|
|2014-12-23 18:53||florianb||Note Edited: 0016085|
|2014-12-24 17:29||drobilla||Note Added: 0016096|
|2014-12-24 17:48||florianb||Note Added: 0016099|
|2014-12-25 17:12||naught101||Note Added: 0016102|
|2014-12-25 17:21||florianb||Note Added: 0016103|
|2014-12-25 17:21||florianb||Note Edited: 0016103|
|2015-05-16 08:45||rgwan||Note Added: 0016696|
|2015-07-13 20:49||ssj71||Note Added: 0016871|
|2017-02-25 16:41||GMaq||Note Added: 0019438|
|2017-02-25 16:42||GMaq||Note Edited: 0019438||View Revisions|
|2017-02-26 01:54||rghvdberg||Note Added: 0019440|
|2017-02-26 06:57||GMaq||Note Added: 0019445|
|2017-02-26 12:46||GMaq||Note Edited: 0019445||View Revisions|
|2018-04-18 20:55||alexmitchellmus||Note Added: 0020259|
|2018-04-18 20:56||alexmitchellmus||Note Edited: 0020259||View Revisions|
|2018-04-18 20:56||alexmitchellmus||Note Edited: 0020259||View Revisions|
|2018-04-18 21:06||alexmitchellmus||Note Edited: 0020259||View Revisions|
|2018-04-18 21:06||alexmitchellmus||Note Edited: 0020259||View Revisions|
|2018-04-18 21:10||alexmitchellmus||Note Edited: 0020259||View Revisions|
|2018-04-18 23:14||alexmitchellmus||Note Edited: 0020259||View Revisions|
|Copyright © 2000 - 2018 MantisBT Team|