Old 03-12-2019, 04:34 AM   #1
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,749
Default MIDI CC envelopes discussion

Since this feature will likely be in development for a while.
schwa is offline   Reply With Quote
Old 03-12-2019, 04:39 AM   #2
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,749
Default

Quote:
Originally Posted by gofer View Post
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.)
schwa is offline   Reply With Quote
Old 03-12-2019, 04:51 AM   #3
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

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!
EvilDragon is online now   Reply With Quote
Old 03-12-2019, 08:32 AM   #4
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
Default

So how will we deal with single events? With regular envelopes it takes 2 points to make a sudden single change.
Tod is offline   Reply With Quote
Old 03-12-2019, 08:55 AM   #5
dupont
Human being with feelings
 
dupont's Avatar
 
Join Date: Nov 2007
Location: France
Posts: 919
Default

I prefer the new behavior with in line CC editing.
It is far easier to draw a curve than adusting several CC bars.
dupont is offline   Reply With Quote
Old 03-12-2019, 09:22 AM   #6
Fergler
Human being with feelings
 
Fergler's Avatar
 
Join Date: Jan 2014
Posts: 5,205
Default

Can we have both? Bars are nicer for certain things, and cleaner to draw if you have a very square response in mind.
Fergler is offline   Reply With Quote
Old 03-12-2019, 05:38 PM   #7
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,669
Default

Quote:
Originally Posted by EvilDragon View Post
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?
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
mccrabney is online now   Reply With Quote
Old 03-12-2019, 06:58 PM   #8
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

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.

__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 09-19-2019, 02:18 PM   #9
Reflected
Human being with feelings
 
Reflected's Avatar
 
Join Date: Jul 2009
Posts: 3,294
Default

Quote:
Originally Posted by EvilDragon View Post
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!
Reflected is offline   Reply With Quote
Old 09-20-2019, 10:04 AM   #10
deeb
Human being with feelings
 
deeb's Avatar
 
Join Date: Feb 2017
Posts: 4,812
Default

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.
deeb is offline   Reply With Quote
Old 09-24-2019, 07:33 AM   #11
deeb
Human being with feelings
 
deeb's Avatar
 
Join Date: Feb 2017
Posts: 4,812
Default

Quote:
Originally Posted by deeb View Post
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?
deeb is offline   Reply With Quote
Old 09-24-2019, 09:44 AM   #12
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by deeb View Post
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.
juliansader is offline   Reply With Quote
Old 03-17-2019, 09:55 AM   #13
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

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.
juliansader is offline   Reply With Quote
Old 03-17-2019, 10:28 AM   #14
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
Default

Quote:
Originally Posted by juliansader View Post
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.
Tod is offline   Reply With Quote
Old 03-20-2019, 02:59 PM   #15
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

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.
srdmusic is offline   Reply With Quote
Old 09-08-2019, 12:36 PM   #16
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

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?
juliansader is offline   Reply With Quote
Old 09-10-2019, 10:45 AM   #17
Quasar
Human being with feelings
 
Join Date: Feb 2007
Posts: 966
Default

Awesome!
Quasar is offline   Reply With Quote
Old 09-30-2019, 03:11 PM   #18
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by juliansader View Post
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
srdmusic is offline   Reply With Quote
Old 09-30-2019, 03:22 PM   #19
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

Quote:
Originally Posted by juliansader View Post
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!
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 09-16-2019, 06:41 PM   #20
deeb
Human being with feelings
 
deeb's Avatar
 
Join Date: Feb 2017
Posts: 4,812
Default

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
deeb is offline   Reply With Quote
Old 09-16-2019, 08:14 PM   #21
ferropop
Human being with feelings
 
ferropop's Avatar
 
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,116
Default

Quote:
Originally Posted by deeb View Post
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.
ferropop is offline   Reply With Quote
Old 09-16-2019, 08:44 PM   #22
puddi
Human being with feelings
 
puddi's Avatar
 
Join Date: Jun 2018
Posts: 375
Default

Quote:
Originally Posted by ferropop View Post
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.
puddi is offline   Reply With Quote
Old 09-17-2019, 03:39 AM   #23
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

yep, +1 from me as well
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 09-17-2019, 03:59 AM   #24
mccrabney
Human being with feelings
 
mccrabney's Avatar
 
Join Date: Aug 2015
Posts: 3,669
Default

Quote:
Originally Posted by puddi View Post
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
__________________
mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.

Last edited by mccrabney; 09-17-2019 at 04:16 AM.
mccrabney is online now   Reply With Quote
Old 09-17-2019, 03:48 AM   #25
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by deeb View Post
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".
juliansader is offline   Reply With Quote
Old 09-17-2019, 07:35 AM   #26
deeb
Human being with feelings
 
deeb's Avatar
 
Join Date: Feb 2017
Posts: 4,812
Default

Quote:
Originally Posted by juliansader View Post
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.
deeb is offline   Reply With Quote
Old 09-17-2019, 01:47 PM   #27
Yanick
Human being with feelings
 
Yanick's Avatar
 
Join Date: May 2018
Location: Moscow, Russia
Posts: 612
Default

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.)
Yanick is offline   Reply With Quote
Old 09-19-2019, 03:36 AM   #28
dupont
Human being with feelings
 
dupont's Avatar
 
Join Date: Nov 2007
Location: France
Posts: 919
Default

Quote:
Originally Posted by Yanick View Post
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.
dupont is offline   Reply With Quote
Old 10-01-2019, 11:43 AM   #29
robgb
Human being with feelings
 
Join Date: Apr 2017
Location: Los Angeles, CA
Posts: 373
Default

Quote:
Originally Posted by deeb View Post
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?
robgb is online now   Reply With Quote
Old 10-01-2019, 11:53 AM   #30
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by robgb View Post
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"?
juliansader is offline   Reply With Quote
Old 10-01-2019, 11:58 AM   #31
robgb
Human being with feelings
 
Join Date: Apr 2017
Location: Los Angeles, CA
Posts: 373
Default

Quote:
Originally Posted by juliansader View Post
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.
robgb is online now   Reply With Quote
Old 10-01-2019, 01:06 PM   #32
robgb
Human being with feelings
 
Join Date: Apr 2017
Location: Los Angeles, CA
Posts: 373
Default

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.
Attached Images
File Type: png Screen Shot 2019-10-01 at 1.00.25 PM.png (49.1 KB, 334 views)
robgb is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:13 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.