|
|
|
03-12-2019, 04:34 AM
|
#1
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,749
|
MIDI CC envelopes discussion
Since this feature will likely be in development for a while.
|
|
|
03-12-2019, 04:39 AM
|
#2
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,749
|
Quote:
Originally Posted by gofer
As of editing other CC lanes, I really miss the old "Edit selected CC, if any - otherwise draw/edit new events", can't remember the exact name.
To illustrate here is an example of editing some typical MPE in v.5.97:
Note that
a) as soon as I select a note, the corresponding CC are selected (as per the option) and come politely to the foreground. Events on the "Channel for new events" are also drawn in the foreground. I can always clearly see which events are ready to be edited. (well, almost, see b )
b) My first attempt to edit the CC which correspond to the red C5 note fails, because "New events channel" is set to a wrong one. It doesn't create anything until I switch to the correct channel. Well, happens. I shrug it off, invoke one of Juliasadder's cool scripts that works wonders for this usecase, and go on.
c) When I edit the greenish C2 note's CC, I drag behind the area of the note, to show that there won't be any events created after the note-off, and the CC which belong to the next note on the same channel are not changed.
In this pre the same data and a similar edit looks like this:
a) The CC get selected alright, but visibility is lots worse. No sign of selected CC and "new events channel" stepping to the foreground. It all smears to a hazy soup.
b) First I redid the same channel mishap as in the 5.97 example trying to edit the red note's CC events. But now Reaper will instantly create events - which happen to be on the same channel as the yellow C6 at the top and thus change its existing CC curve. I need to undo, so I swear a little. I prefer the old behavior.
c) Editing the greenish note demonstrates how Reaper will now start creating CC out of bounds of the note, and what's worse, also change the existing CC curve of the next note on that same channel.
For editing MPE data it's currently a step backward. Looking forward to see the next iteration
|
Some very good points here. The main thing these comments illustrate is that there will need to be different editing behaviors between track envelopes and CC-data-as-envelopes, even if they look similar.
The default mouse behavior that was previously "Edit selected CC events if any, otherwise draw/edit" currently gets re-mapped to "Edit selected velocities, or freehand draw CC events." But it seems like the old behavior needs to be restored, though probably not as the default behavior. (And who knows, maybe we should add that mouse modifiers for track envelopes as well.)
|
|
|
03-12-2019, 04:51 AM
|
#3
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
Yes, please restore old behavior as a new mouse modifier! And yes, consistency is good, so having the same modifier for track envelopes would be excellent.
Remember Steve Ballmer? His thing was DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS.
DAWs (and most programs) should in fact be CONSISTENCY CONSISTENCY CONSISTENCY CONSISTENCY!
|
|
|
03-12-2019, 08:32 AM
|
#4
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
|
So how will we deal with single events? With regular envelopes it takes 2 points to make a sudden single change.
|
|
|
03-12-2019, 08:55 AM
|
#5
|
Human being with feelings
Join Date: Nov 2007
Location: France
Posts: 919
|
I prefer the new behavior with in line CC editing.
It is far easier to draw a curve than adusting several CC bars.
|
|
|
03-12-2019, 09:22 AM
|
#6
|
Human being with feelings
Join Date: Jan 2014
Posts: 5,205
|
Can we have both? Bars are nicer for certain things, and cleaner to draw if you have a very square response in mind.
|
|
|
03-12-2019, 05:38 PM
|
#7
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
Quote:
Originally Posted by EvilDragon
And yes, consistency is good, so having the same modifier for track envelopes would be excellent.
|
this is why i get confused when left click in cc/velocity lane doesn't move the edit cursor. is there a reason for this difference in behavior that i have overlooked?
|
|
|
03-12-2019, 06:58 PM
|
#8
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
I think we also need a new representation of curves in the arrangement (items).
Both items show a ramp down at the end of the item. One consists of 2 points and the other one of multiple points. In the case of the first, the curve itself is not conceivable.
|
|
|
09-19-2019, 02:18 PM
|
#9
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,294
|
Quote:
Originally Posted by EvilDragon
DAWs (and most programs) should in fact be CONSISTENCY CONSISTENCY CONSISTENCY CONSISTENCY!
|
I can love you for saying that again and again and again
please keep it up!
I should create a +1 bot to trace your consistency related posts :P
+1 for consistency!
|
|
|
09-20-2019, 10:04 AM
|
#10
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,812
|
I'd like to be have this (CCs and Envelopes)
Imagine we have several points selected.
I would like a Drag modifier that allows to expand/compress selection points values according to the drag position relative to selection (left, center, or right of selection) and the height of the drag.
Example 1: selected values are:
0, 0, 0
+ modifier and Drag up on the right side of selection (maximum height drag)
= Would Update values to 0, 64 , 127
Example 2: selected values are:
0, 0, 0
+ modifier and Drag up on the left side of selection (maximum height drag)
= Would Update values to 127, 64 , 0
Is it understandable what i mean? : )
Edit: more clear I think
Last edited by deeb; 09-21-2019 at 06:55 AM.
|
|
|
09-24-2019, 07:33 AM
|
#11
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,812
|
Quote:
Originally Posted by deeb
I'd like to be have this (CCs and Envelopes)...
|
i would like just to be sure my request is understandable,
schwa: do you know what i mean?
|
|
|
09-24-2019, 09:44 AM
|
#12
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by deeb
I would like a Drag modifier that allows to expand/compress selection points values according to the drag position relative to selection (left, center, or right of selection) and the height of the drag.
Example 1: selected values are:
0, 0, 0
+ modifier and Drag up on the right side of selection (maximum height drag)
= Would Update values to 0, 64 , 127
|
Basic straight lines such as these can be drawn using the native "Linear ramp" mouse modifier. For more complex tilting and compression, you can try my scripts (link in my sig below).
(EDIT: Of course, using CC envelopes, straight lines can also be drawn with two points and a single segment.)
Last edited by juliansader; 09-24-2019 at 10:21 AM.
|
|
|
03-17-2019, 09:55 AM
|
#13
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Since we are discussing envelopes in the MIDI editor... How about displaying the tempo envelope in a CC lane?
This would allow editing tempo while looking at the actual notes being affected.
Tempo-related actions can be passed through to Main, so tempo *markers* can already be added and edited in the MIDI editor, but the tempo *envelope* cannot be drawn.
Last edited by juliansader; 03-21-2019 at 05:47 AM.
|
|
|
03-17-2019, 10:28 AM
|
#14
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
|
Quote:
Originally Posted by juliansader
Since we are discussing envelopes in the MIDI editor... How about displaying the tempo envelope in a CC lane?
This would allow editing tempo while looking at the actual notes being affected.
Tempo-related actions can be passed through to Main, so tempo *markers* can be added and edited in the MIDI editor, but the tempo *envelope* cannot be drawn.
|
Hummm, trying to imagine this Julian. It could be nice for Orchestration and all midi projects, in fact it could be a real plus to adjust tempo while creating all midi projects.
Might work well with video projects too.
|
|
|
03-20-2019, 02:59 PM
|
#15
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
I have to say thank you again to the Dev team for working on this. THis truly is one of the best updates you guys have ever come up with.
I'm staying on version +dev0308a which seems to be the most stable version of the envelopes.
The later versions had a bug when the user draws a midi node into in any CC lane, it would also write the same node value into all other visible lanes. I can take video of the problem if that helps narrow down a solution.
Last edited by srdmusic; 03-20-2019 at 03:08 PM.
|
|
|
09-08-2019, 12:36 PM
|
#16
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
CC curves are back in v5.983+dev0829!
I would like to make a few more suggestions:
64-bit PPQ for high resolution:
At present, REAPER appears to store ticks as a signed 32-bit integers. (Functions such as MIDI_Get/SetAllEvts store ticks as 32-bit integers, and the maximum PPQ that can be entered in Preferences is 2^31-1.) This means that PPQ is limited to a maximum of about 32000, if 4-hour long MIDI items with fast bpm have to be accommodated.
How about storing ticks as 64-bit integers instead, and using something like 2^50 bits as default PPQ? This would give MIDI a resolution that is almost as fine as REAPER's 64-bit floating time values, would remove all problems with snapping to grid, and would make MIDI sample-accurate. Users would not need to deal with ticks and PPQs any more, except when importing and exporting MIDI.
(A few other DAWs such as Digital Performer have already taken this step.)
Position instead of offset:
In the MIDI stream (as given in the item chunk or MIDI_Get/SetAllEvts), the positions of MIDI events are stored as tick offsets relative to the previous events:
Code:
E 0 b0 01 5e
E 960 b0 01 60
E 960 b0 01 5c
E 1080 b0 01 52
E 840 b0 7b 00
In contrast, the positions of envelope points are stored as absolute time positions:
Code:
PT 0 1 0
PT 0.5 1 0
PT 1 1 0
PT 1.5 1 0 0 1
Would it not be much easier for MIDI to work with tick positions relative to the start of item, rather than with offset from previous event?
|
|
|
09-10-2019, 10:45 AM
|
#17
|
Human being with feelings
Join Date: Feb 2007
Posts: 966
|
Awesome!
|
|
|
09-30-2019, 03:11 PM
|
#18
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by juliansader
CC curves are back in v5.983+dev0829!
I would like to make a few more suggestions:
64-bit PPQ for high resolution:
At present, REAPER appears to store ticks as a signed 32-bit integers. (Functions such as MIDI_Get/SetAllEvts store ticks as 32-bit integers, and the maximum PPQ that can be entered in Preferences is 2^31-1.) This means that PPQ is limited to a maximum of about 32000, if 4-hour long MIDI items with fast bpm have to be accommodated.
How about storing ticks as 64-bit integers instead, and using something like 2^50 bits as default PPQ? This would give MIDI a resolution that is almost as fine as REAPER's 64-bit floating time values, would remove all problems with snapping to grid, and would make MIDI sample-accurate. Users would not need to deal with ticks and PPQs any more, except when importing and exporting MIDI.
(A few other DAWs such as Digital Performer have already taken this step.)
Position instead of offset:
In the MIDI stream (as given in the item chunk or MIDI_Get/SetAllEvts), the positions of MIDI events are stored as tick offsets relative to the previous events:
Code:
E 0 b0 01 5e
E 960 b0 01 60
E 960 b0 01 5c
E 1080 b0 01 52
E 840 b0 7b 00
In contrast, the positions of envelope points are stored as absolute time positions:
Code:
PT 0 1 0
PT 0.5 1 0
PT 1 1 0
PT 1.5 1 0 0 1
Would it not be much easier for MIDI to work with tick positions relative to the start of item, rather than with offset from previous event?
|
+10000 This would be amazing
|
|
|
09-30-2019, 03:22 PM
|
#19
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Quote:
Originally Posted by juliansader
CC curves are back in v5.983+dev0829!
I would like to make a few more suggestions:
Position instead of offset:
In the MIDI stream (as given in the item chunk or MIDI_Get/SetAllEvts), the positions of MIDI events are stored as tick offsets relative to the previous events:
Code:
E 0 b0 01 5e
E 960 b0 01 60
E 960 b0 01 5c
E 1080 b0 01 52
E 840 b0 7b 00
In contrast, the positions of envelope points are stored as absolute time positions:
Code:
PT 0 1 0
PT 0.5 1 0
PT 1 1 0
PT 1.5 1 0 0 1
Would it not be much easier for MIDI to work with tick positions relative to the start of item, rather than with offset from previous event?
|
Oh yes, please, I'm constantly pulling my hair!
|
|
|
09-16-2019, 06:41 PM
|
#20
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,812
|
i had a little time to test the cc curves! it's fantastic
1) I wonder if this could be possible: at this moment seems like when we editing 1 envelope and drag a point horizontal it wont move vertical and then if we start drag vertical it won't move horizontal. Could drag do both: move X and y?
2) could we have an option just like we have for envelopes so that reaper "prevent mouse edits of single envelope from moving past other cc points" and have a different behaviour then this when passing an adjacent point
Thanks
|
|
|
09-16-2019, 08:14 PM
|
#21
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,116
|
Quote:
Originally Posted by deeb
i had a little time to test the cc curves! it's fantastic
1) I wonder if this could be possible: at this moment seems like when we editing 1 envelope and drag a point horizontal it wont move vertical and then if we start drag vertical it won't move horizontal. Could drag do both: move X and y?
2) could we have an option just like we have for envelopes so that reaper "prevent mouse edits of single envelope from moving past other cc points" and have a different behaviour then this when passing an adjacent point
Thanks
|
Agree with both of these. It should feel as though we're in the Arrangement envelope lanes in every way -- points should move both X and Y and not pass one another.
|
|
|
09-16-2019, 08:44 PM
|
#22
|
Human being with feelings
Join Date: Jun 2018
Posts: 375
|
Quote:
Originally Posted by ferropop
Agree with both of these. It should feel as though we're in the Arrangement envelope lanes in every way -- points should move both X and Y and not pass one another.
|
Yes, I agree with both of you. There shouldn't be much (or any?) difference working with CC envelopes and automation envelopes imo. Consistency would improve too.
|
|
|
09-17-2019, 03:39 AM
|
#23
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
yep, +1 from me as well
|
|
|
09-17-2019, 03:59 AM
|
#24
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
Quote:
Originally Posted by puddi
Yes, I agree with both of you. There shouldn't be much (or any?) difference working with CC envelopes and automation envelopes imo. Consistency would improve too.
|
except could we PLEASE not allow for this (i know about "don't move envelopes with copy," but you can still end up in this situation if you left an envelope selected):
i'll often be editing a section of my project, only to zoom out and see that i'd created a mess like this out-of-zoom due to it being in the time selection
this is another example of edge-case functionality being better supported than more fundamental, single-envelope editing, and it'd be good to head it off in midi cc envelopes
Last edited by mccrabney; 09-17-2019 at 04:16 AM.
|
|
|
09-17-2019, 03:48 AM
|
#25
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by deeb
1) I wonder if this could be possible: at this moment seems like when we editing 1 envelope and drag a point horizontal it wont move vertical and then if we start drag vertical it won't move horizontal. Could drag do both: move X and y?
|
Go to Mouse Modifiers -> CC event -> Default left-drag, and UNclick "On one axis only".
|
|
|
09-17-2019, 07:35 AM
|
#26
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,812
|
Quote:
Originally Posted by juliansader
Go to Mouse Modifiers -> CC event -> Default left-drag, and UNclick "On one axis only".
|
Thank you!
Will look at it later .. would be nice if shift could bypass this option.
And other modifier to bypass the other option I asked earlier (if ever implemented): prevent mouse edits of single envelope from moving past other cc points"
Edit: some of this might be already implemented, .. will check later .. thanks
Last edited by deeb; 09-17-2019 at 08:39 AM.
|
|
|
09-17-2019, 01:47 PM
|
#27
|
Human being with feelings
Join Date: May 2018
Location: Moscow, Russia
Posts: 612
|
Be sure to add the option to add points without moving the edit cursor. Because in other sections of mouse modifiers there is such an opportunity (media item, midi editor notes, etc.)
|
|
|
09-19-2019, 03:36 AM
|
#28
|
Human being with feelings
Join Date: Nov 2007
Location: France
Posts: 919
|
Quote:
Originally Posted by Yanick
Be sure to add the option to add points without moving the edit cursor. Because in other sections of mouse modifiers there is such an opportunity (media item, midi editor notes, etc.)
|
yes, currently I find it is not accurate to draw a point.
|
|
|
10-01-2019, 11:43 AM
|
#29
|
Human being with feelings
Join Date: Apr 2017
Location: Los Angeles, CA
Posts: 373
|
Quote:
Originally Posted by deeb
i had a little time to test the cc curves! it's fantastic
1) I wonder if this could be possible: at this moment seems like when we editing 1 envelope and drag a point horizontal it wont move vertical and then if we start drag vertical it won't move horizontal. Could drag do both: move X and y?
2) could we have an option just like we have for envelopes so that reaper "prevent mouse edits of single envelope from moving past other cc points" and have a different behaviour then this when passing an adjacent point
Thanks
|
Going a bit crazy here. I can't find anything like this in the latest dev. versions. Is it gone?
|
|
|
10-01-2019, 11:53 AM
|
#30
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by robgb
Going a bit crazy here. I can't find anything like this in the latest dev. versions. Is it gone?
|
What are you referring to by "this"?
|
|
|
10-01-2019, 11:58 AM
|
#31
|
Human being with feelings
Join Date: Apr 2017
Location: Los Angeles, CA
Posts: 373
|
Quote:
Originally Posted by juliansader
What are you referring to by "this"?
|
The ability to manipulate CC curves as in the gif above. I'm able to draw the curves, but can't create separate nodes like above.
UPDATE: Okay, I got it figured out. Had to make some adjustments in preferences.
Last edited by robgb; 10-01-2019 at 12:47 PM.
|
|
|
10-01-2019, 01:06 PM
|
#32
|
Human being with feelings
Join Date: Apr 2017
Location: Los Angeles, CA
Posts: 373
|
Next question: Is there any way to get rid of the highlighting of a section when the node is selected? I find it very distracting.
|
|
|
Thread Tools |
|
Display Modes |
Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 07:13 AM.
|