In the MIDI Editor, shouldn't we have a Controller lane for Poly Aftertouch? (That message type can be selected in the Event Properties drop-down list.)
If not, then how do you edit them?
__________________ DarkStar ... interesting, if true. . . . Inspired by ...
To improve the workflow a little, you can draw the desired poly aftertouch fade curve in another CC lane, and then use Properties to quickly change the CCs into poly aftertouch. (And vice versa if you want to edit existing poly aftertouch events).
Yes, I did that but as soon as the events are converted to Poly Aftertouch they disappear from the piano roll / controller lanes view and are only visible in the Event List.
__________________ DarkStar ... interesting, if true. . . . Inspired by ...
Perhaps this FR will be implemented sooner if we can make detailed suggestions to the devs.
My suggestions:
* PATs can be displayed and edited in the MIDI editor in a CC lane, like other CCs. (I think this will be easier to implement than the original FR.)
* When notes/velocities are colored by pitch, PATs will also be colored by pitch.
* When drawing PATs, they will be drawn in the piano roll's currently active note pitch.
* When selecting a note and "CC selection follows note selection" is active, only PATs in the same pitch as the note get selected. (Similar to how only CCs in the same channel get selected.)
* When moving note to a new pitch, the selected PATs must also change pitch.
* New action: Select all PATs in active pitch.
I'm not sure how PATs should be colored when notes are colored by velocity. Monocolored like other CCs? Colored by pitch? Perhaps by velocity of matching notes?
Great suggestions! I think treating them like other CCs and linking them to active notes makes sense to at least get them into a decently editable state. Then any subsequent improvements to CC editing will also apply to PAT.
Quote:
Originally Posted by juliansader
Perhaps by velocity of matching notes?
Either this or monocolored makes the most sense to me, when notes are colored by velocity.
I definitely see the benefit of that. What would the requisite tools for working with those events be? A drawing tool linked to a mouse modifier that kicked in at a certain zoom level perhaps? A lot of the stuff I’ve done with PAT so far hasn’t utilized a visual representation in a DAW so I’m trying to picture the necessary tools that would accompany this.
Yes, depending on vertical zoom level, you'd get like a track envelope for each item. Or, to be consistent with how CC lanes are done, blocks
Another option would be modifier+doubleclicking a note, a window opens for drawing in PAT events for the duration of the note (similar to Note Expression in Cubase) - since PAT events make no sense when a note is not pressed, of course.
Yes, depending on vertical zoom level, you'd get like a track envelope for each item. Or, to be consistent with how CC lanes are done, blocks
Another option would be modifier+doubleclicking a note, a window opens for drawing in PAT events for the duration of the note (similar to Note Expression in Cubase) - since PAT events make no sense when a note is not pressed, of course.
Well, I do like the first option if it is elegantly implemented And don't give them any ideas about more blocks!
The second option seems a bit easier. I might not do as much MIDI editing as you guys, but how does the separate window idea differ from treating PAT like other CC in the CC lane? Just to make it clearer for our request, why a separate envelope or window would be better than CC. Since it seems like a lot of these features get shaped heavily by use cases brought up by us.
Yes, depending on vertical zoom level, you'd get like a track envelope for each item. Or, to be consistent with how CC lanes are done, blocks
Another option would be modifier+doubleclicking a note, a window opens for drawing in PAT events for the duration of the note (similar to Note Expression in Cubase) - since PAT events make no sense when a note is not pressed, of course.
I think there may be a few disadvantages of within-note PAT editing:
* Difficulty visualizing and comparing PAT for multiple notes: In the case of the zoom option, a few notes' PAT can be seen at the same time, but constant zooming-in and zooming-out would be a hassle.
* Difficulty editing PAT for multiple notes: If, for example, the PAT value range for multiple notes needs to be expanded.
* I will miss my scripts: SWS's API functions and my own scripts will not work in new within-note mini MIDI editors, unless the SWS functions are extensively updated.
* PAT and notes may lose alignment: If PATs are inadvertently de-selected while editing notes, subsequent note editing such as quantization will cause the notes and their PATs to lose alignment. Wayward scripts or overlapping notes can possibly also cause misalignment. I think REAPER should be able to easily edit (and bring back into alignment) PATs that are not connected with any notes. (Although, REAPER does manage to keep notes and their notation text events nicely in alignment, so perhaps it can reliably do the same for PATs.)
* PATs are not necessarily limited to MIDI note duration: I have not encountered this myself yet, but it is conceivable that VSTi's can respond to PATs even after the note-off. Drumkits, for example, often send zero-length notes since the drum VSTi's ignore note-offs and instead play samples till the next hit or choke.
* Difficulty visualizing and comparing PAT for multiple notes: In the case of the zoom option, a few notes' PAT can be seen at the same time, but constant zooming-in and zooming-out would be a hassle.
Well, other DAWs have it implemented like that (Bitwig, FL Studio), and it works nicely there.
Quote:
Originally Posted by juliansader
* Difficulty editing PAT for multiple notes: If, for example, the PAT value range for multiple notes needs to be expanded.
That wouldn't be a problem if we could marquee across multiple notes. Consequently, CC lanes
Quote:
Originally Posted by juliansader
* I will miss my scripts: SWS's API functions and my own scripts will not work in new within-note mini MIDI editors, unless the SWS functions are extensively updated.
Of course API would need to be updated, that's a given.
Quote:
Originally Posted by juliansader
* PAT and notes may lose alignment: If PATs are inadvertently de-selected while editing notes, subsequent note editing such as quantization will cause the notes and their PATs to lose alignment. Wayward scripts or overlapping notes can possibly also cause misalignment. I think REAPER should be able to easily edit (and bring back into alignment) PATs that are not connected with any notes. (Although, REAPER does manage to keep notes and their notation text events nicely in alignment, so perhaps it can reliably do the same for PATs.)
PATs go where the note goes, simple as that. No way to lose alignment. It's like permanently having enabled "move envelope points with media items", just applied to PAT events.
Quote:
Originally Posted by juliansader
* PATs are not necessarily limited to MIDI note duration: I have not encountered this myself yet, but it is conceivable that VSTi's can respond to PATs even after the note-off. Drumkits, for example, often send zero-length notes since the drum VSTi's ignore note-offs and instead play samples till the next hit or choke.
Technically, I guess so, but in practice, when you actually HAVE a device that outputs PATs, you can only send them while you hold a key, since it's obviously afterTOUCH, not afterRELEASE.
* PATs are not necessarily limited to MIDI note duration: I have not encountered this myself yet, but it is conceivable that VSTi's can respond to PATs even after the note-off. Drumkits, for example, often send zero-length notes since the drum VSTi's ignore note-offs and instead play samples till the next hit or choke.
Technically, I guess so, but in practice, when you actually HAVE a device that outputs PATs, you can only send them while you hold a key, since it's obviously afterTOUCH, not afterRELEASE.
I don't have an e-drum to prove it, but I think that choking cymbals is sent as an aftertouch event. With EZdrummer you have to send a non-zero aftertouch before a zero aftertouch to make a cymbal stop ringing. But as Julian points out the MIDI note has no "real" length.
Anyway, this is no show-stopper. Better to have usable poly aftertouch support for keys only rather than have none at all.
PATs go where the note goes, simple as that. No way to lose alignment. It's like permanently having enabled "move envelope points with media items", just applied to PAT events.
Ideally, the PAT data timing should be referenced (glued-on) to the preceding Note-ON event:
- If you move the note forward or backward in time (without changing duration), the PAT data should follow the note.
- If you change the selected note's pitch (or use transpose), the PAT data should be changed to reference the transposed note.
- If you change the note's duration, there should be a selectable option that either 1) makes the PAT data expand or compress to the new Note-OFF event, or (2) leave the data alone during note's duration and delete PAT data that rolls off past Note-OFF if the note is made shorter.
- Also the ability to "thin" the PAT data would be nice. Having too much PAT data can saturate a MIDI stream, and this would average PAT data that is too closely together.
REAPER DEVS -- PLEASE ADD GRAPHICAL PAT EDITING TO REAPER. It's needed badly with new synths that have hit the market recently - such as Deckard's Dream, etc. Even without a polyAT keyboard, having the ability to add and edit PAT data graphically in the DAW will add tremendous amount of per-note control to the user, something that is difficult to do otherwise without multitracking.
User interface should show a preview of PAT data within the note bar in the piano roll, and when the note is selected, it should appear in the CC editing area below if that option is selected, with data moving around when the selected note is moved.
I understand that there are only a few devices that send poly aftertouch but devices using MPE Midi (maybe together with poly aftertouch, but I suppose they usually will to channel aftertouch) are on the rise ( ).
Hence support for MPE might be additionally appropriate. In fact I have no idea how this should look like, but rather obviously poly-aftertouch and poly pitchbend, and poly-whatever CC are supposed to look very similar in an editor.
MPE uses channel aftertouch. I am using ROLI Seaboard Blocks and love it. Editing MPE in Reaper is pretty good with the exception of pitch bend. Those are not purposefully editable in Reaper. ROLI MPE uses a bend range of 48 semitones, which results in barely visible event bars in Reaper's MIDI editor for the more usual bends - let alone vibrato gestures. This thread https://forum.cockos.com/showthread.php?t=177868 has some pics to demonstrate the problem and thoughts about what would be needed.
I don't necessarily want to see all MPE data like Channel Aftertouch and CC74 right on the notes, as that would likely introduce an extra step for selecting which one is to be edited. Right now "CC selection follows note selection" gracefully deals with it and Juliansadder's "js_Option - Selecting single note or CC in active take sets channel for new events.lua" is tremendously helpful, too. Ok, I constantly move the mouse between notes area for selection and CC lanes for edits, but I can live with that.
But in case of MPE Pitch Bend it would be the only way that makes sense to me - and of course for Poly Aftertouch, to at least say something related to the thread topic.
+1 to any solution that makes Poly Aftertouch events easily visible and editable.
Maybe I'm missing something, but at the time of posting this, on macOS version of Reaper (v5.963) I cannot find any way to easily create, see and edit Poly Aftertouch events. I could make them by drawing Channel Pressure events, then selecting those, opening View -> Event Properties and changing type to "Poly Aftertouch".
I used the free u-he Zebralette VST synth for testing. It allows controlling modulation of its parameters ("Mod" in GUI) with Poly Aftertouch ("Pressure" in GUI). For example, setting modulation source of "Pan" to "Pressure", then "Pan" to -100 and "Mod" to 100, allows panning individual notes with Poly Aftertouch (0=left, 127=right).
After manually editing Poly Aftertouch values in MIDI Editor's Event List, Zebralette responded as expected, panning notes separately according to Poly Aftertouch values. I tested this with other Zebralette parameters (Tune, FX, etc.) as well. Other u-he synths also support Poly Pressure, as well as some other synths mentioned elsewhere on this forum.
My suggestion for quick improvement to Poly Aftertouch editing in Reaper is similar to juliansader's:
1. when a single note is selected, allow (with a shortcut key, UI button etc.) showing in CC lane the Poly Aftertouch events tied to its pitch.
In other words, selecting notes would work as pitch selector for deciding which Poly Aftertouch events are shown in CC lane. When moving notes that have PAT events in their pitch, their PAT events should move too.
2. in the piano roll / named notes pane on the left, pitches that have Poly Aftertouch events in current MIDI take could be marked with letters "PolyAT" (for example) so user knows that those pitches have PAT events.
This would probably be faster to implement than showing PAT data inside notes.
Beyond that, EvilDragon's suggestion seems like most refined long term solution.
On a general note, it's surprising that despite being part of MIDI spec, even in 2019 Polyphonic Aftertouch is not supported in all DAWs, nor a highly requested feature. Perhaps if it was called Polyphonic Automation it'd be better understood?
Perhaps someone can post some annotated pics of how other DAWs implement PAT Editing. (I am not sure how to interpret EvilDragon's pic.)
So far I'm most familiar with Poly Aftertouch (Poly Pressure) in Cubase, where it's done via feature called Note Expression.
Per-note automation data is overlaid on top of notes in piano roll (at least since Cubase 8) and a special editor window is opened for editing it.
Steinberg have a video of it on Youtube, named "Note Expression & MIDI Articulations | Advanced Features in Cubase 7" - it's at about 2:40.
Attached is a screenshot of per-note editor window from Cubase 8, with multiple notes selected.
In FL Studio it is done via using FL's internal modulation parameter (Mod X). Polyphonic aftertouch can be linked to it, and as far as I've tested, it works only per note-on events. In other words, no automation during the note itself (or at least I haven't found a way to do that).
Attached is a screenshot of piano roll window from FL Studio 20.
In Bitwig Poly Aftertouch is reportedly supported via per-note automation but I have not tested that yet so cannot comment.
Ableton Live does not support Poly Aftertouch at all, as far as I know.
Personally I got fairly comfortable using the Cubase implementation, though per-note editor window was by default a bit too small.
As far as I understand, note expression (per-note automation) is also a part of VST3.5 standard, and it is not the same thing as Poly Aftertouch. I don't know how note expression of VST3.x is implemented in Reaper, so cannot comment on that.
Meanwhile Poly Aftertouch data support is present in Reaper, so I think allowing editing of PAT data in CC lanes would be a good next step.
I'm bumping this up as there are now more and more MIDI controllers and synths coming out that support polyphonic aftertouch, and Reaper is woefully incapable of graphically editing this data. I was hoping this would make it to v6, but it did not happen. I'm not talking about MPE (an entirely different thing). pAT is a dedicated MIDI data that provides expression control for each note with a single MIDI channel. Reaper records and plays it back currently, but the only way to edit it is in the event list, which is unusable for any serious editing work.
Poly-aftertouch capable controllers:
- Osmose by Expressive E
- Hydrasynth by ASM
- Behringer is working on a CS80 clone with pAT.
- and of course older controllers, such as the Midiboard, are still in use.
Can this be implemented soon? Pretty, pretty please.
This can be implemented simply as a selection in the CC list. And when you highlight a note it will show the pAT data graphically, which should move with the note, just like the current CC data does. I think this can be easily made to work with all the existing UI elements and most of the code as shown below in a mockup:
Poly-aftertouch capable controllers:
- Osmose by Expressive E
- Hydrasynth by ASM
- Behringer is working on a CS80 clone with pAT.
- and of course older controllers, such as the Midiboard, are still in use.
Interesting !
Funnily, Roli decided not to use Poly AT for their Seaboard.
Looking at MIDI files from EZdrummer (various libraries), all notes have some length.
If you use an edrum kit to record, how is it handled by those? I never recorded one, but would think that hitting a cymbal will just trigger a note with some fixed (non-zero, of course) length. Then if you grab the cymbal rim to mute it, the according PAT message will be triggered. This may happen well after the note-off.
So while using a keyboard PAT will only be triggered while the note actually runs, if my hunch is right then edrum kits are different. If that’s the case, on-note-editing will need to have the ability to include events which come after the note-off.
Interesting !
Funnily, Roli decided not to use Poly AT for their Seaboard.
-Michael
As long as MPE is realised using multi channel, there is no reason for them to use PAT. Would only stress the MIDI stream more without added benefit. (edit: actually I am not sure, but think PAT are larger than CAT messages?)
I’d like to see the option anyway, for single channel use cases.
Their upcoming Lumi keyboard which isn’t MPE is supposed to be able to do PAT.
This can be implemented simply as a selection in the CC list. And when you highlight a note it will show the pAT data graphically, which should move with the note, just like the current CC data does.
This looks good! I guess it would be quite achievable, and could bring all the benefits of recent automation curve enhancements. I read earlier discussions about restricting PolyAT drawing to note bounds, which have some logic as PolyAT is typically only processed by instruments between note ons and offs. However, there is only one PolyAT 'lane' per KEY (in each channel), and not per NOTE. Sometimes I would want to 'score' the PolyAT automation, keeping it fixed in place while unilaterally moving the relevant notes in time. So I think we'd have maximum flexibility if PolyAT can be manipulated just like existing CC, respecting the *option* for CC selection follows note selection.
Some thought needs to be given as to whether selection-following should include note transposition, and whether only note bounds are then respected (as with CC). But you probably wouldn't want to slowly drag a note up an octave and hypothetically plough through an octave's worth of PolyAT data. In this scenario, having selection-following via transposition only happen on mouse release would work, but what about note-shifting via keyboard shortcuts?
It would also be good to have some means of identifying which keys have PolyAT data, irrespective of note events in the MIDI item. Options include populating the CC selector drop-down, or better still, some highlighting on the piano roll keys.
For now (until support for MIDI 2.0 and its per-note controllers is added to REAPER),
I'd be happy with simply having Polyphonic Aftertouch events visible in a CC lane when a note is selected.
So CC selector drop-down menu would have, in addition to current options, 128 Poly Aftertouch lanes named like "Poly AT C#3" and so on.
Problems with selecting multiple notes could be avoided by:
A) disallowing selecting notes of multiple pitches when a Poly Aftertouch lane is visible:
the selection would pick only highest note in selection, and the Poly AT lane would change to that selected note
or
B) if notes of multiple pitches are selected, Poly AT lanes for each selected note would be shown, in same Y-axis order as pitches of selected notes.
As notes are deselected, Poly AT lanes would be hidden.
There could be settings and actions for exact behaviors regarding this.
Meanwhile, I wonder if it'd be possible to script an editing window for Poly Aftertouch events, per selected note, with following logic:
Code:
--get MIDI note (pitch) of selected note
--get NoteOn of selected note (position from MIDI source start)
--get NoteOff of selected note (position from MIDI source start)
--get MIDI events (with positions from MIDI source start)
--find PolyAT events (if type = PolyAt etc.)
--if PolyAT event MIDI note == selected MIDI note
--and PolyAT event position is > selected note NoteOn
--and PolyAT event position is < selected note NoteOff
--then
--show PolyAT events in an editing window
--[[
No idea if/how such a window is doable.
Ideally, on X-axis it'd correspond visually to note length
and have adjustable setting for height of the window
so that at some setting it'd be possible
for Y-axis to correspond to piano roll pitches etc.
AFTER EDITING IS DONE BY USER and new PolyAT events are in an intermediate table etc.:
- delete previous PolyAT events of same pitch and time window as selected note
- write new PolyAT events to MIDI source
- probably they need to be sorted to be in
correct time positions among other existing MIDI events
--]]
Unfortunately my own REAPER scripting skills are below trying that, at this time.
I suppose it's also possible to try making a hacky script to change PolyAT events - per selected note - to another CC event type and back, so that they could be edited with existing MIDI Editor. That would obviously require running such script every time one wants to edit (get) and commit (set) PolyAT events for any given note.
128 poly aftertouch lanes are overkill, really. Talk about a kludge...
Agreed, it's inelegant in terms of UI, but unless I have seriously misunderstood things, that's what Poly Aftertouch effectively is: a CC lane for each of 128 MIDI note numbers [aka keys aka pitches].
In REAPER, looking at data in Event list and .RPP files, the Poly AT events are simple and per MIDI spec:
E [PPQ from previous event] [message type and channel] [MIDI note number aka key/pitch] [value]
To see Poly AT envelopes as per-note graphs, one would need to categorize Poly AT events by MIDI note [pitch], thus creating "lanes" anyway.
So I was thinking about this as question of tradeoff between development effort and functionality. To my understanding, presenting Poly AT events in CC lanes would be the easiest way to allow visual editing of Poly AT, as it'd be mostly a matter of writing a function to format Poly AT data for existing editor interface (and the reverse).
While not the ideal UI solution, I think it'd be much better than current situation of only seeing Poly Aftertouch events in Event list. And for users who do not wish to see Poly AT lanes in CC drop-down, a "Show Poly Aftertouch lanes" setting in MIDI Editor's View menu would suffice.
I would rather if devs spent their time not half-assing it but doing it properly and at least decent UX. What you propose is not decent UX IMHO.
Doing it in a style like Bitwig or FL Studio do it is halfways to supporting note expression, too...
I agree that more refined UX would be better than using CC lanes, and that other DAWs have good examples of possible solutions. And especially that per-note expression - including MIDI 2.0 and its per-note controllers - is the way for the future.
But for now, from perspective of using REAPER to edit Poly AT data in practice, I would much prefer even rudimentary "Poly AT in lanes" functionality over current manual workarounds.
For comparison, the current manual workaround for editing Poly Aftertouch is:
1. select Poly Aftertouch events of notes/keys you want,
2. change their type to CC (note number becomes CC number),
3. edit them as CC
4. change their type back to Poly Aftertouch.
Interestingly, since note number automatically becomes CC number, it seems that developers have already thought of this. Editing can be done in one or several lanes at a time, except that instead of note names the CC lanes show CC numbers. Using "Named notes" view helps with this.
However, if there are a lot of different MIDI events in the item, selecting Poly AT events manually from Event list is impractical, so PolyAT-CC-PolyAT conversions must be scripted or done as text editing to the .RPP file.
A native function to show Poly AT events in lanes would almost certainly *not* require changing event types, picking Poly AT events manually, or editing a .RPP, or other such workarounds. Admittedly, it'd be a small step from the current situation, but a step in the right direction nevertheless.
Consider it this way: if CC lane solution would be implemented, we'd at least have a baseline direct functionality for editing Poly AT in the GUI. After that, it'd be possible to test different use cases and tell developers if, where and why UX improvements might be needed.
To be fair, it's not really half-assed to propose lane-based representation of lane-based data.
Sure. But that lane should not be visually disconnected from the note it belongs to, which is why it shouldn't be in the CC lanes area, but on the note itself. Just like note expression.