|
|
|
05-04-2019, 04:35 AM
|
#81
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,032
|
Can Reaper get interval lines from note to note in piano roll* as well? See the link below, where I added graphics and explanations.
* https://github.com/michaelsjackson/r...orums/issues/1
|
|
|
05-04-2019, 04:43 AM
|
#82
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
That has nothing to do with CC envelopes discussion, at all.
|
|
|
05-04-2019, 04:48 AM
|
#83
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,032
|
But it has with piano roll, where midi cc envelopes are part of, so why only improving the envelopes but not the notes? Both is better, as the source codes should be same place, you know my friend.
|
|
|
05-04-2019, 04:49 AM
|
#84
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
What's the title of this thread? Does it contain "piano roll" in it? It doesn't. So, you're off-topic.
|
|
|
05-04-2019, 05:05 AM
|
#85
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,032
|
I am in-topic in the off topic, btw. for listening to midi compositions I am not using Reaper at all, loading midi files in Synthesia, loading synths in buze, all in wine in linux, watching the played notes in Synthesia, all wonderful, wonderful display, wonderful sound, even when used cheapest piano vst like S-YXG50, advantage is low cpu consumption, thanks to great reverbs available for buzz, like HALYverb and Funkyverb.
midi > Synthesia > buze > S-YXG50 (piano vst) > HALYverb || Funkyverb.
Piano enjoyment in purest and simplest form.
Now what is missing is the analysis part. What is available is MusicGraph, but as a Reaper user, Reaper could take over this job, wonderfully, getting best composition and analysis environment. Synthesia and buze as best playing environment, if you do not want to compose anything, not analyze anything, just enjoying listening to great midi compositions.
|
|
|
05-05-2019, 09:41 AM
|
#86
|
Human being with feelings
Join Date: Jul 2011
Posts: 82
|
Quote:
Originally Posted by EvilDragon
What's the title of this thread? Does it contain "piano roll" in it? It doesn't. So, you're off-topic.
|
The dragon sometimes has his red cheeks
Totally off topic, but the forum seems less polite now 2c
|
|
|
05-05-2019, 11:14 AM
|
#87
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
I agree with ED. It was completely off topic and should have been posted in Feature Requests not here. It literally had nothing to do with CC Envelopes and isn't relevant to the discussion and testing of this new CC implementation.
|
|
|
05-06-2019, 06:16 AM
|
#88
|
Human being with feelings
Join Date: Nov 2015
Posts: 12
|
Quote:
Originally Posted by EvilDragon
There's no modifier for square mode, there's a default curve option for MIDI CC envs in Prefs->Editing Behavior->MIDI Editor that is by default set to square. You don't have to do anything.
|
Sorry, but I can't find this in Prefs->Editing Behavior->MIDI Editor. Where can I set the default curve mode? Did a search in preferences, no result.
|
|
|
05-06-2019, 06:31 AM
|
#89
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
That option is not there in the current CC envelopes implementation. It was in the older one, several dev cycles ago.
|
|
|
05-06-2019, 09:56 AM
|
#90
|
Human being with feelings
Join Date: Nov 2007
Location: France
Posts: 919
|
Quote:
Originally Posted by EvilDragon
That option is not there in the current CC envelopes implementation. It was in the older one, several dev cycles ago.
|
Is the CC envelopes feature still planned.
|
|
|
05-06-2019, 10:18 AM
|
#91
|
Human being with feelings
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,109
|
Quote:
Originally Posted by dupont
Is the CC envelopes feature still planned.
|
schwa's comment about it:
https://forum.cockos.com/showpost.ph...0&postcount=72
|
|
|
05-06-2019, 01:43 PM
|
#92
|
Human being with feelings
Join Date: Nov 2007
Location: France
Posts: 919
|
Quote:
Originally Posted by nofish
|
thanks, so let's wait.
|
|
|
07-11-2019, 08:13 AM
|
#93
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
REAPER is step-by-step moving away from the plain MIDI standard. First, MIDI events got flags for selected and muted states, then notation was added, and now CC envelopes.
Perhaps this is a good time to completely re-think how REAPER stores MIDI data.
In particular, notes can be transformed into miniature "items" that store more than just a note-on:
* Instead of separate note-ons and note-offs, each note event can store the note length. This will avoid all the problems with overlapping notes that get infinitely extended or chopped off.
* Each note can store its own polyphonic aftertouch events, which will allow REAPER to eventually develop something similar to Cubase's "note expression".
* Each note can store its own notation, so that scripts don't have to search the MIDI stream for a matching notation event.
|
|
|
07-11-2019, 11:40 AM
|
#94
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by juliansader
Perhaps this is a good time to completely re-think how REAPER stores MIDI data.
In particular, notes can be transformed into miniature "items" that store more than just a note-on
|
This would be absolutely brilliant and really the ultimate goal.
|
|
|
07-11-2019, 11:56 AM
|
#95
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
Yep, I like the idea as well.
|
|
|
07-14-2019, 04:39 AM
|
#96
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,672
|
Quote:
Originally Posted by juliansader
* Instead of separate note-ons and note-offs, each note event can store the note length. This will avoid all the problems with overlapping notes that get infinitely extended or chopped off.
|
yes, extremely important.
this will also allow for items that contain midi notes that extend past the item end. this crucial for pickups and chords whose notes don't all begin at item start/x.1.1.
if i'm trying to split/copy move the above chord, where a strum is simulated, i cannot split on the 3.1.1 without creating unwanted multiple notes. desired behavior: the first 2 notes go in item 1, full length, and the 3rd note goes in item 2, full length.
in the MPC series, "items" were called "sequences" and behaved as described above. you could go from one sequence/item to another and long notes held from the previous sequence would keep playing until their length had been reached (this was overridden by the stop button)
i'm aware of snap offset, but that presents its own problems (overlapping midi items) in the case where you're pasting midi over existing midi. overlapping midi items are horror for people using midi overdub.
Quote:
In particular, notes can be transformed into miniature "items" that store more than just a note-on
|
"track-based midi." whatever it takes to get the workflow without breaking scripts.
Last edited by mccrabney; 07-14-2019 at 04:50 AM.
|
|
|
09-08-2019, 12:36 PM
|
#97
|
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
|
#98
|
Human being with feelings
Join Date: Feb 2007
Posts: 966
|
Awesome!
|
|
|
09-16-2019, 06:41 PM
|
#99
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
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
|
#100
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,127
|
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
|
#101
|
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
|
#102
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
yep, +1 from me as well
|
|
|
09-17-2019, 03:48 AM
|
#103
|
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, 03:59 AM
|
#104
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,672
|
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, 07:35 AM
|
#105
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
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
|
#106
|
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
|
#107
|
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.
|
|
|
09-19-2019, 02:18 PM
|
#108
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,295
|
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
|
#109
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
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
|
#110
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
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
|
#111
|
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.
|
|
|
09-24-2019, 04:43 PM
|
#112
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
Thank you JS but i don't think i am talking the same thing.
I don't really want to drag a line and drawing it my self with linear ramp.
Also i have the idea that your script also does not allow editing existing values, but i have to check again.
The request is that by dragging vertically (not horizontely) , up on the right of this selected evens
would produce this result:
Another example:
applying in this events:
would produce this:
This is like apply ramp (up or down) from left to right when modifier applied on the right side.
And the benefit is that we don't have to draw anything new, but use existing points and scale / ramp them.
Cubase as this feature , .. but i have no way to make a licecap of it. Can Anyone do it?
Last edited by deeb; 09-24-2019 at 04:53 PM.
|
|
|
09-24-2019, 05:04 PM
|
#113
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
Here:
Quote:
Originally Posted by juliansader
For more complex tilting and compression, you can try my scripts (link in my sig below).
|
|
|
|
09-24-2019, 06:18 PM
|
#114
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
_Stevie_: lfo tool is great, but i'd encourage you to try the process of going from here:
to here using lfotool:
Anyway! again lfo tool is great, but What i am talking is very simple and not complex and does not need a GUI. Is a drag up or down on one side of selection (or whatever way or first and last event maybe) and reaper would apply a linear ramp up or down over the existing values in a way that the more the event is near the drag side more maximize/compression is applied.
This is very controllable and predictable way of using existing envelopes and fine ramp them manually.
Last edited by deeb; 09-24-2019 at 06:27 PM.
|
|
|
09-24-2019, 11:57 PM
|
#115
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
I was actually referring to the "Scripts for MIDI editing", such as:
Arch/Tilt:
or Stretch/Compress (which was recently updated to work with CC envelopes):
I tried to make the "look and feel" of these scripts very similar to REAPER's native mouse modifiers, just more advanced.
|
|
|
09-25-2019, 03:55 AM
|
#116
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
Quote:
Originally Posted by juliansader
I was actually referring to the "Scripts for MIDI editing", such as:
|
Yes, me too. I never referred to the LFO tool.
deeb, you should really take the time and read thru Julian‘s thread. There’s a lot of info and pretty much
every midi / cc usage is covered there.
|
|
|
09-28-2019, 10:14 AM
|
#117
|
Human being with feelings
Join Date: Feb 2017
Posts: 4,820
|
Ok I'll probably will have to use this method (and is very welcome) still I think native modifier to linear compress/expand would be better workflow for this use case and would be enough for most of my needs.
|
|
|
09-28-2019, 04:33 PM
|
#118
|
Human being with feelings
Join Date: Apr 2016
Posts: 118
|
Hi!
2 questions about curves:
1) I use a B/W e-ink display (8 levels of gray). New CC curves are great! but, as you can see in att. photos, they almost invisible. Is there a way to set colors for different curve components, especially the contour of an unselected curve?
2) My midi controller (Roland FR-3XB) sends CC11 slow with noticeable steps (as on att. picture). Is there a way to record this data directly with a linear transition between points? (to transform on the fly during midi recording a curve to one of the modes, for example, Bezier or linear)
|
|
|
09-30-2019, 03:11 PM
|
#119
|
Human being with feelings
Join Date: Dec 2016
Posts: 880
|
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
|
#120
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
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!
|
|
|
Thread Tools |
|
Display Modes |
Linear 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 12:48 AM.
|