| Users sponsoring this issue (Total Sponsorship = US$ 90) |
|
2013-07-21 15:55
|
velocity track.png (137,658 bytes) |
|
|
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. |
|
|
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. |
|
2014-12-24 02:08
|
Ardour_MIDI_Velocity_channel.png (31,833 bytes) |
|
|
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. |
|
|
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. 0006055 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... http://dl.florianbador.com/20141224-ardour-5608.png 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. |
|
|
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). |
|
|
*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, Glen |
|
|
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. |
|
|
Hi, @rghvdberg 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 http://bandshed.net/images/screenshots/ReaperMIDI2.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. |
|
|
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: https://photos.app.goo.gl/fNC4yzKd0Fh7pV323 MIDI MPE Data in Note: https://photos.app.goo.gl/KOqyF4hTB4WrUdaQ2 |
|
|
I think that visualizes the event values nicely, but certainly doesn't provide an easy way to manipulate them. I still think that the biggest need is to be able to quickly "draw" dynamics, the same way you can with fader automation on an audio track. I think a lollipop thing to visualize AND manipulate the velocity info, be it overlay or another lane is the most logical way, though it probably needs a few editing modes like snap to value and scale to support a few use cases. I can't think of any way to do this that isn't a departure from current capabilities in ardour. "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." I don't see that as much improvement over the current situation of using mousewheel and color to visualize. I think rghvdberg's point is the essence of this feature request: 1 click+drag to manipulate many notes' velocities. The problem remains that note events have 3 degrees of freedom (4 if you include channel) and we only have 2D screens to visualize and edit on. When Ardour VR comes out we'll laugh that this was ever an issue. ;) |
|
|
As far as editing goes, a "multiplication ramp" tool might be good, and require very little in the way of new interface. For example: 1. Select a bunch of notes 2. context menu -> velocity ramp 3. Draw a line in the current midi track, where the bottom of the track = 0, and the top = 1 (or 2?). 4. When the ramp is finished, multiply each note's current velocity value by the value at the corresponding position in the ramp. This would be nice because it would allow you to maintain some of the relative variation between consecutive notes (rather than just over-writing the values. The line drawing could have a couple of different options: 2 or more points (linear ramps in between), bezier curves, or free-hand draw. Hit enter to finish and apply the ramp. If there's a tool configuration dialogue, it could include things like adding humanisation to the ramp (add a random component from 0-50%). |
|
|
VIEW NOTE VELOCITY WHEN NOTE IS SELECTED: I put together a mock-up in Ardour doing this to gtk2_ardour/note_base.h: inline static uint32_t meter_style_fill_color(uint8_t vel, bool selected) { /* if (selected) { return _selected_mod_col; } else */ Example: https://www.youtube.com/watch?v=xMjDTRr5FO0 I experimented with other ideas: * Dimming color of note outline * Dimming color of note fill However it was not clear to me when I was using Ardour which notes were selected. If the outline can become 2 pixels then maybe these other methods would work better. However I think that 1 pixel has been chosen for a reason. (maybe only when selected the outline becomes 2 pixels?) Also this video outlines an issue when changing multiple notes velocities. (which is already evident to any user of MIDI and Ardour) Which is that once the MIDI velocity becomes 0 or 127 there is no way to adjust the additional notes up or down. Other software solves this issue by saturating the high and low values. However due to Ardour using the scrollwheel for Velocity adjustment it makes it impossible to calculate 'velocity change start' events. As there can always be velocity change events. In other software the start event is simply left click when using a dedicated velocity tool. Thus the delta of the mouse movement can be translated to velocity up and down.(Which gives the user the ability to decide how much to move the velocity without loosing too much velocity information for saturated values.) NOTE: The only issue with my solution is if the user sets one of the three velocity colors to the same as the selected color there will be no way to see selected notes. However as all colors are user changeable, this could be easily fixed by the user by selecting a 'selected color' that is not present in the velocity colors. |
|
|
Here is a concept of placing velocity line 'inside' each MIDI note: https://photos.app.goo.gl/C28ahFYy7qDxBwRu6 https://www.youtube.com/watch?v=M_nsnZYAAMA&feature=youtu.be Combined with the above: VIEW NOTE VELOCITY WHEN NOTE IS SELECTED Also increased the outline size of all MIDI notes to 2px (originally 1px) (out.patch above is a Git patch that contains this working concept. Not a pull request, or intended for production- only to work out ideas) |
|
|
out.patch (5,825 bytes) |
|
|
Velocity_Editor.png (201,856 bytes) |
|
|
+---------------------- IDEA ONLY------------------------+ I am not even 100% I like it myself posted to build a conversation around Velocity Editing +----------------------------------------------------------+ I uploaded an image of an 'In Region' Note Velocity Editor. The idea is to be able to select notes, then right-click and be able to select from the Note menu the "Velocity Editor". The Velocity editor would then show (as in the mock-up) the range of notes selected, and show a lollypop graph above the highest selected note. It would be good to have a 'pen' tool, (for freehand drawing of velocities), and also a bezier curve tool (to allow any sort of velocity ramp to be drawn). Any note that was not selected (when entering the tool would not be able to be edited. Possibly notes could be included and excluded on-the-fly while the tool is activated? If notes overlap (as in same temporal position, then the drawn curve velocity would effect all notes (and give them all the same velocity for that time). There would also be an exit box on the top right to close the tool, and return to normal note editing. |
|
|
alex: the master branch now has the basics of your patch, reimplemented as discussed on IRC. What's missing is color management. I think that's all. |
|
|
I set up the code to automatically compute the right color based on the fill color. I think that HSV::opposite() is probably too radical .. try playing with HSV::darker() ... ? |
|
|
color now works as it did in your patch. |
|
|
and the bars can be turned on and off. |
|
|
Absolutely amazing work Paul! Thank you so much for taking the time to implement this. Here are some additional thoughts (in no order) that I am thinking could help MIDI editing in Ardour work better. (some dot points are simply changing settings- or adding a preference): * A way to edit velocity of multiple notes (as per this thread) as either an overlay or lane. * Clearly showing MIDI regions (currently zoomed out- and in, its a bit hard to see the MIDI region from the canvas)-Theme:Cubasish does this well. * MIDI Region (and Audio Region) end loop tool (drag end of region to loop, loop connects to same region, but can be changed in future edit. * Making the outline of the white/black note rows able to be translucent, (like the white/black note row colors are) Currently the row outlines can become very busy visually, and actually don't help in locating which note is which as everything looks white(or the set color) *(DONE) Velocity bar can be thinner? And also able to not show based on note vertical/horizontal height (this could already work). * In note text (note name and velocity) and/or with velocity? EG: "A#4:127" * Ability to change note outline thickness (currently 1px, could be 2px?) this may make a good preference. * Smarter track zooming (when making track vertically larger) the MIDI region could expand to show more content? Instead of simply zooming in? * When moving a note up/down highlight the whole note bar that it is currently on. * Resound MIDI notes while changing velocity (as this is an audio software, it is good to hear the note velocity as well as see it) * For resounding MIDI notes it may be better to have a dedicated velocity tool (or use the current 'Internal Edit Tool' to LMB a note and drag up/down to change velocity) as currently both 'DRAW MODE TOOL' and 'INTERNAL EDIT TOOL' have the same behavior when LMB clicking. (possibly we can use the middle mouse button for velocity change? MMB could be utilized more) *(DONE) More note state colors: Currently there are 3, which only shows visually Low, Mid, High. [0,64,127] 5 Note states would show: Min, Low, Mid, High, Max. [0,32,64,96,127] Changes to "DRAW MODE TOOL" & "INTERNAL EDIT TOOL": Currently RMB is not used for anything in Draw mode (when no notes are selected), it could be used to 'highlight notes' which can then also be moved with the same tool (LMB). Then we don't need to worry about moving notes with the "Internal Edit Tool". Thus possibly we should be able to control velocity when LMB onto the selected notes in "Internal Edit". (currently both Note Edit, and Internal Edit both do same thing, and I wouldn't consider moving notes to be 'internally editing notes', rather editing 'note content' would be internal. Velocity is currently one of the only internal 'note' attributes we can edit. If MPE is implemented, 'Internal Edit' could also be used for those values 'inside' notes as well (because LMB would no longer move the whole note): Per-Note: * Note-on (strike) * Note-off (lift) * Aftertouch (press) * Pitch-Bend, X-Axis (glide) * Y-Axis (slide) If (in the future) MPE is implemented, then showing 'internal' velocity bars is simply just one attribute of "show internal note data". Thus we should be able to select (per track) what sort of internal data we want to display (and edit). Already there could be two modes for "show velocity bars", Note-on velocity, and Note-off. |
|
|
thinnervline_01.patch (1,055 bytes) |
|
|
I attached a patch to make the in-note horizontal velocity lines thinner, with a 1px gap at either end. I think this looks a bit less visually imposing. see: 'thinnervline_01.patch' above Screenshot: https://photos.app.goo.gl/dayGEAZuG976G6QL7 |
|
|
Another idea I had for a solution to the 'lollipop' display. (Not implemented) How about showing selected notes velocities vertically as an overlay on the piano roll editor. https://photos.app.goo.gl/m4ArvA7woFQNRwqE7 User would: 1) Select multiple notes (or one note) 2) RMB notes and select from menu "Lollipop Editor" 3) Lollipop editor shows as overlay on screen, (only selected notes are displayed) 4) Freehand draw with LMB 5) Vector draw with RMB (click to create two points to draw a line between) 6) RETURN key to apply line values to note velocities 7) ESC key to leave "Lollipop Editor" mode |
|
|
Simple_Velocity_Automation_Lane.jpg (115,291 bytes) |
|
|
Having thought about this for a while, I think that actually a simple velocity automation lane would suffice. (Simple, as in the ideas that I have proposed previous were probably quite complex- not implementation). Mockup "Simple_Velocity_Autiomation_Lane.jpg" To solve the 'polyphony issue' I would suggest to only be able to edit selected notes. As this is an automation lane (I know technically its not automation) but due to there being another lane, the user would be able to add or remove editable velocity lollipops by selection in the main midi region view. Possibly a first iteration of this idea lane could simply be drawing velocity with the pen tool, or changing velocity up - down. No tools for velocity ramps - lines etc. which could come later. |
|
|
Here is an example of a rudimentary (read Hack) change I made to Ghostregions that displays their notes as lollipops in an automation view. https://youtu.be/1wc2YDuLIjw Currently there is no editing, but it at least shows what it 'could' look like in Ardour. The lollipop lane is currently just an automation track, (without any automation in it). I have attached ghostlollipop_patch.diff for anyone interested. I can see this working such as: * Automation header menu has 'velocity' checkbox * When 'velocity' checkbox is toggled, a velocity layer is added * The velocity lane will always be underneath the associated track * If no MIDI notes are selected in a MIDI region, then all lollipops will be editable * If there are selected MIDI notes then only those would be editable in the velocity lane (to preserve polyphonic velocity editing) * Access to two tools: Pen (to draw velocity in) & Line (to draw lines) |
|
|
ghostlollipop_patch.diff (3,928 bytes) |
|
|
wow, this is brilliant. now you need to look into the Drag code (editor_drag.{cc,h}) to see how to implement velocity dragging :) |
|
|
@paul, I personally don't like the idea of velocity dragging for all notes. But I do think that lollipops should be able to be: * Drawn into * Adjusted (selected notes) * Get value from drawn line over all selected lollipops. In regard to 'velocity automation', enumerating lollipop should allow us to pass this as a automation track type? Which would be drawn along with all the other automation tracks? It looks like currently global tracks are dealt with elsewhere so I am not sure if this should be the same place. |
|
|
@alexmitchellmus Is that the right patch? I may well be mistaken, but it seems to be a patch relative to another change (there is a line with an ALEX comment removed). Did you perhaps not diff against master? |
|
|
I'm really surprised that there isn't more pressure about this. Minutes ago I was drawing drum notes, I wanted a velocity curve for a roll on the toms and suddenly realised there's no other way than setting the individual velocities one by one. Coming from a well known commercial DAW that I'm determined to abandon - I want to use Linux and open source software exclusively - this is extremely weird to me and it might even be a deal breaker. |
|
|
there's less pressure than even i'd expect, and i think it is mostly because the vast majority of people rarely (if ever) do this. it is another one of those workflow things where for one set of users, this is, as you put, a dealbreaker, and for a different (and much larger) set of users, it's mostly of little consequence. that's true of almost all features already present or missing in any given DAW, including ardour. i do have a plan for this at this point, and it will better than you see in many other DAWs, i believe. designing the details is a bit of a headache, though. |
|
|
This is awesome news. I'm learning to love your software and I really want to stick to it. I guess I'll mousewheel my velocities for a little longer, knowing you're working on something is great |
|
|
OK all you whiners :))) Ardour 8.0 is out with your beloved lollipops implemented, along with freehand drawing. And Leatuspenguin, I hope you're still at the same email address - this may be the first of your always excellent suggestions that we've actually implemented in a decade now. |
|
|
I finally got a chance to test it and it's amazing. Thank you so much |
