|
|
|
06-27-2020, 05:59 AM
|
#1
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
Allow midi noteoffs to exist/function outside of item endpoint ("dangle")
there's been lots of talk about this FR, so it needs its own thread in the right forum.
the term "dangle" has been used to describe a request for REAPER to allow midi noteoffs to exist/function outside the endpoint of an item. this would allow users to split midi items without splitting the notes themselves -- note ends would be associated with the items that contain their note ons.
here's a post showing the "dangle" as implemented in JJOS for the MPC. sorry for the big pictures. use forum theme titled "reaper 5" to make them auto-resize
and here's a post showing how REAPER creates extra noteons/noteoffs during looped recording.
Quote:
Originally Posted by mccrabney
recording MIDI in a looped section of REAPER's arrange is problematic. if you are holding a note over the loop point, REAPER forces a NOTEOFF at loop end and creates a NOTEON at loop start.
in this gif, i twice demonstrate record myself hitting 1 noteon and 1 noteoff, across the loop point.
in both cases, REAPER records this as 2 noteons and 2 noteoffs, at beginning and end of the loop.
use any synth with a slow attack on the filter to immediately see why the above behavior is wrong.
yes, it looks sensible, and yes, it follows an internal logic - but it is wrong and leads to a lot of user error, small unwanted notes, and post-recording cleanup.
essentially, REAPER is not accurately recording what is being played.
REAPER should not insert additional noteoffs and noteons into recorded midi. if a user records a note that dangles past the item and loop bounds, that noteoff should be recorded where it drops -- outside the bounds. at midi noteon, REAPER should calculate the duration of the note before the noteoff, and play the note in full - even if the noteoff is beyond the item/loop bounds.
for another example: look what happens to this strummed chord as it gets split by this problematic behavior:
the goal was to record 3 notes: REAPER instead records 5! look at those awful tiny notes in the beginning of the looped section. the only way to get the desired behavior is to not use looped sections at all, and manually return to the desired startpoint at every rec start.
the current behavior is like having an instrument that randomly retriggers itself while you're holding sustained notes.
|
Last edited by mccrabney; 08-19-2023 at 04:50 AM.
|
|
|
06-30-2020, 01:20 AM
|
#2
|
Human being with feelings
Join Date: Dec 2018
Posts: 503
|
Big +1 to this.
To my understanding, in simplest form, this means allowing a MIDI item to contain Note Off events at time positions beyond the end/loop of the MIDI item.
As said in another thread, this will most likely require following changes:
1) using some other way of marking a MIDI item loop instead of All Notes Off.
Perhaps MIDI meta-event or something REAPER-specific, as was done with CC point shapes?
2) adding logic (and possibly new user-configurable settings) for behavior of "dangling notes" in various situations, such as when MIDI item looping results in new Note Ons happening before "dangling" Note Offs.
|
|
|
09-04-2020, 03:20 PM
|
#3
|
Human being with feelings
Join Date: Oct 2019
Posts: 1,075
|
+1
One of my 2-3 pet peeves. This can't be that hard to implement at least as an option, now can it?
|
|
|
04-07-2022, 06:17 PM
|
#4
|
Human being with feelings
Join Date: Oct 2019
Posts: 1,075
|
Bumping this.
Allowing "dangling" notes at the end of MIDI items would result in increased symmetry/elegance: splitting a MIDI item would make no difference in sound, while now it produces a repeated note (when the split happens during the sustained note). So the sequence split / glue is not idempotent. Which is A Bad Thing.
Apart from considerations of symmetry and elegance, as it is now editing a midi part by splitting, copying and pasting is harder than it should be. Depending on the content, it often requires the user to create overlapping items for long notes extending into the beginning of the next item. This in turn requires an additional auxiliary track to host such items.
|
|
|
04-08-2022, 05:00 AM
|
#5
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
if we're dreaming big, we might even expand this fr to allowing note ons to exist before items as well, to allow for strummed chords/pickups to be associated with their intended midi items
this really isn't that "outside the box"
|
|
|
04-08-2022, 07:15 AM
|
#6
|
Human being with feelings
Join Date: Oct 2019
Posts: 1,075
|
Indeed, pre-start events would be useful even more often. Not only anacrusis for strums etc, but sustain switches, control changes, program changes as well... since we're dreaming, I will wish for that, too, tyvm.
Now I'm not a developer, but this pre-start business seems a little harder than post-end, since no other DAW that I know has anything similar. It would probably involve something like a "transparent" pre-start section for MIDI items - which would not cover/trim underlying items, regardless of user preferences. This looks like quite some reworking.
On the other hand, post-end dangling note ons seem like they would involve a representation of a note on as start+length rather than start+end. Maybe it's already like this, but, say, the event queues are per-item, so everything must be dealt with before the item expires.
I have no idea about the internals of Reaper, so I'm just wildly guessing. I doubt anyone needs that, so I'll stop here.
It would make MIDI editing a whole lot easier though!
|
|
|
02-09-2023, 04:29 AM
|
#7
|
Human being with feelings
Join Date: Jan 2022
Posts: 10
|
Quote:
Originally Posted by mccrabney
if we're dreaming big, we might even expand this fr to allowing note ons to exist before items as well, to allow for strummed chords/pickups to be associated with their intended midi items
this really isn't that "outside the box"
|
Oh yes! Totally! Those are two things that'd be great - in my case in drum programming. Quantizing is not my thing and sometimes the first kick comes before the item starts - putting it at the end of a loop is one option, but it's a workarround that requires more work later and can be problematic at times.
|
|
|
06-07-2023, 07:14 AM
|
#8
|
Human being with feelings
Join Date: May 2020
Posts: 337
|
Big +1 from me on this as well, it makes unquantized MIDI loop recording a pain in its current form.
For now I'd settle for any script/workaround to just move the early note on/off from the previous take to the start of the current one, but I haven't managed to find a script or figure out a custom action to do this without having to stop playing and go back to fiddly mouse editing.
|
|
|
06-07-2023, 07:27 AM
|
#9
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,031
|
I guess somebody needs to present an algorithmic solution to this situation, so devs can implement it. Maybe they can not see/find any algorithmic solution yet? Which other reason they might have not implementing it?
|
|
|
06-07-2023, 07:52 AM
|
#10
|
Human being with feelings
Join Date: Oct 2019
Posts: 1,075
|
I'm afraid the algorithmic side of things is quite clear to the developers. I suspect the problem lies in the data structures. How are items - and specifically, MIDI note on/off events inside items - represented?
If the current representation makes it complicated to have the "dangle" - or more so, the "pre-dangle", things might stay as they are for quite a while. It is hard to redesign or change the underlying data structures without restructuring a significant part of the software.
I hope I'm mistaken, and some feature list in a pre-release proves me wrong!
|
|
|
06-08-2023, 01:29 AM
|
#11
|
Human being with feelings
Join Date: Nov 2017
Posts: 1,575
|
I honestly have to say I'm against it. This feature would bring more
confusion than benefit.
Because the top priority should be that the graphic image, i.e. the
arrangement and the image of all items, reflects what is really there.
This means that all notes are included in the items, not outside of
them! Note-offs are also within the items. Always!
Anything else would - in complex projects where we already have
muted items, invisible automations and automation items - cause a
lot of confusion and impair intuitive working too much!
In the case of an item split, as a user you have to:
1. Always split where there is no note overlap.
2. If no point without note overlap can be found, then the item
containing the long note must be lengthened backwards. With FIPM
"on" you can let the items overlap - that's simple and elegant.
As a result, what is happening in the arrangement is always
represented by what you can see visually. Exceptions to this rule
are dangerous and error-prone. I wouldn't allow them, even as
an "option".
|
|
|
06-08-2023, 04:21 AM
|
#12
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
please take your concerns back to the 80s and 90s when they were developing these hardware sequencers.
"i can't handle the complexity, therefor it shouldn't be an option for others" is not a compelling argument.
|
|
|
06-08-2023, 06:34 AM
|
#13
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,031
|
It should work in Reaper as it worked in old hardware, no it should work even better, but not worse, please. Thanks friends. devs, help.
|
|
|
06-08-2023, 06:38 AM
|
#14
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,031
|
Quote:
Originally Posted by juan_r
I'm afraid the algorithmic side of things is quite clear to the developers. I suspect the problem lies in the data structures. How are items - and specifically, MIDI note on/off events inside items - represented?
|
Data structure should not be problem. Note on and note off are two different events. Those are connected in our minds only, or the synths engine's mind, if not used pairwise resulting in hanging notes problem, where you are hunting for the PANIC button, remember the nice face in Cakewalk 3? I added a PANIC toolbar button to left top, for such situations. Data structures should not be the problem, I guess, it should be something else. Maybe devs can write one two sentences of their thought and decision criteria for adding or not adding this feature. Not sure if anybody defined this feature request anywhere precisely, so it is very clear for the devs, without any need for any guesswork.
|
|
|
06-08-2023, 06:39 AM
|
#15
|
Human being with feelings
Join Date: Nov 2017
Posts: 1,575
|
Quote:
Originally Posted by mccrabney
please take your concerns back to the 80s and 90s when they were developing these hardware sequencers.
|
The hardware sequencers had no visual representation. That's why I
can understand if something like this was implemented as an option
in the past.
But we live in a time of visual representation and quick visual
access. And it's important, especially in the field of music, that
you can work intuitively. Music has a lot to do with emotion and
intuition.
Quote:
Originally Posted by mccrabney
"i can't handle the complexity, therefor it shouldn't be an option for others" is not a compelling argument.
|
Reaper in particular already suffers from the "Optionism" disease:
You can set an infinite number of options, and every newcomer is
initially overwhelmed by the options. Reaper has the reputation of
being the "Linux among DAWs": So highly complex and difficult to
use, actually only software for nerds.
In this respect, I find the addition of another option, which is
nonsensical anyway, problematic.
|
|
|
06-08-2023, 07:06 AM
|
#16
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
i posted literal pictures of hardware with visual representation of the FR in the first post.
Quote:
Reaper in particular already suffers from the "Optionism" disease:
|
oh ffs, go troll somewhere else
|
|
|
06-09-2023, 11:30 PM
|
#17
|
Human being with feelings
Join Date: Feb 2009
Location: Reaper HAS send control via midi !!!
Posts: 4,031
|
Quote:
Originally Posted by enroe
Reaper in particular already suffers from the "Optionism" disease:
You can set an infinite number of options, and every newcomer is
initially overwhelmed by the options.
|
I agree about the Optionism. But with Reaper this is already the case. Adding one more option, beside the million already available does not change much. Reaper's way is adding a function in code, then adding its toggle checkbox SOMEWHERE in the software, maybe in Preferences somewhere, or you need to discover, find by accident, find 5 years later via a YouTube video, this toggle existed already many years. Then you can use this "well hidden" function.
And if the entire software consists of such options, it is no wonder, newcomers or oldstayers are overwhelmed. One only needs to stop trying to know all functions and features in the software. You can instead take your personal notes, what you want to achieve for which goal. Gradually completing it multiple options in Reaper, via reading in forums, trying yourself, watching YouTube, and so on. Then when discovered a great workflow for some goal, writing again your personal notes, not to forget it again.
Then, Reaper is perfect. Because you can do anything you want.
Reaper presents you all the atoms (functions, toggle options), the molecules (custom workflows) you need to build yourself.
Other software offer some molecules, that's it, if you do not like the available molecules there, bad luck. In Reaper, build whatever molecule you can think of. Much cooler.
Oh I forgot, the new Reaper sales motto: Reaper, the One Million Options DAW
(There is still space for 5 Million more options)
Last edited by TonE; 06-09-2023 at 11:48 PM.
|
|
|
06-10-2023, 05:25 AM
|
#18
|
Human being with feelings
Join Date: Nov 2017
Posts: 1,575
|
Quote:
Originally Posted by TonE
I agree about the Optionism. But with Reaper this is already the case. Adding one more option, beside the million already available does not change much. Reaper's way is adding a function in code, then adding its toggle checkbox SOMEWHERE in the software, maybe in Preferences somewhere, or you need to discover, find by accident, find 5 years later via a YouTube video, this toggle existed already many years. Then you can use this "well hidden" function.
And if the entire software consists of such options, it is no wonder, newcomers or oldstayers are overwhelmed. One only needs to stop trying to know all functions and features in the software. You can instead take your personal notes, what you want to achieve for which goal. Gradually completing it multiple options in Reaper, via reading in forums, trying yourself, watching YouTube, and so on. Then when discovered a great workflow for some goal, writing again your personal notes, not to forget it again.
Then, Reaper is perfect. Because you can do anything you want.
Reaper presents you all the atoms (functions, toggle options), the molecules (custom workflows) you need to build yourself.
Other software offer some molecules, that's it, if you do not like the available molecules there, bad luck. In Reaper, build whatever molecule you can think of. Much cooler.
Oh I forgot, the new Reaper sales motto: Reaper, the One Million Options DAW
(There is still space for 5 Million more options)
|
Haha, yes TonE, you're right!
What sets Reaper apart from other DAWs is that it has an incredible
number of functions. Most of these are just executable functions.
But they can also be integrated via the menu, and the user can create
a shortcut or a button for it.
I find it funny: You describe yourself as a lonely forest sprite who
clears his way with a bush knife, makes his way through the thicket,
and thus creates his own red line, "his workflow". He usually stays
on his way, but sometimes explores the big, dark forest here and
there.
But if you read through the manual, for example, then you approach
the forest "as a whole" and you get a different impression: Reaper is
also well thought out and promotes a very specific "Reaper workflow".
The track and routing concept, for example, is a bit more abstract
than in other DAWs, with advantages and disadvantages. It provides
for a certain Reaper-specific handling of the routing.
What I mean to say is that you don't have to break through the forest
like a lonely forest sprite! You can also systematically explore the
forest. But of course everyone finds their own way.
----------------------------------------------------------------------
If you follow the development of the "Fixed Track Lanes", then you
can already see that it is a struggle to realize the most elegant
workflow possible. And that the goal is not to simply make
everything possible, but rather to realize an intuitively understandable,
elegant handling of the lanes.
The question is always: Which concept am I pursuing as a developer?
How can I find a really good solution? How can I embed solutions into
the existing one?
And with these conceptual considerations, I believe that with the
arbitrariness of all options and possibilities, the software itself will
dissolve and ultimately be destroyed.
First there is no more ergonomics, and then there is no one who really
understands what they are doing. So if you expand "Takes", "Items"
and "Lanes" so far that each of them can also be the other, then you
have achieved real arbitrariness. At some point, the software can no
longer be used and can no longer be handled by developers.
That's why I'm in favor of more stringency - in the workflow, in the
functions, etc. That would be in the interests of the users and also in
the interests of the developers. I think so howsoever. Ultimately, of
course, Justin and John decide, and a lot of things just happen
"organically".
|
|
|
06-10-2023, 07:08 AM
|
#19
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
^ content free. word salad.
thanks for the bump and support though
|
|
|
08-17-2023, 11:00 AM
|
#20
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
+1
|
|
|
09-23-2023, 01:27 PM
|
#21
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Agree 100% with the request. It is not unusual at all. Logic allowed „dangling notes“ from the very beginning back in the emagic days, never had any trouble with it. The opposite is true, it allows for edits to be easy as pie which are very troublesome in Reaper. Alas somewhere in this forum exists a reply from Schwa saying that this will very likely not happen in Reaper. I found it to be the most frustrating dev response ever.
|
|
|
12-13-2023, 02:50 PM
|
#22
|
Human being with feelings
Join Date: Aug 2023
Posts: 22
|
Big +1 to this.
|
|
|
12-14-2023, 06:31 AM
|
#23
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
this has an adjacent request involving more options around how Razor Edits select, split, and copy midi. see that thread here: https://forum.cockos.com/showthread.php?t=238943
right now, REs will automatically split MIDI notes where the note on occurs before RE start. this obliterates any strummed chords that occur over RE selection and changes the recorded performance in an undesirably way. this process can be show in the first 28 seconds of this gif. note my red outline indicating the true length of the longer MIDI note being unwantedly split by the RE: the cymbal's noteon gets moved to the start of the RE, which is not the same performance as what was copied.
this disobeys "what you see is what you get," because i don't see a noteon in my original Razor Edit selection. this is the desired behavior, and my script works, but is a bad workaround for what ought to be optional (i'd argue default, but it's understandably too late for that) native behavior
after 28 seconds, i demonstrate a kludgy script that i wrote which uses an RE to make a selection, but only copies the MIDI whose noteons exist within the RE: ignoring those notes which "dangle" into the RE selection.
if REs could optionally ignore MIDI notes whose noteons exist outside the RE, we could be more selective in what we're editing with RE selections. see here, trying to comp these MIDI passages result in changes to the timing/sound of the performance. strummed or arpeggiated chords get clipped and truncated in a way that you can't really fixed with a single fixed lane:
Quote:
whereas if these selection boxes only comped notes whose NOTEONs exist within the box, we'd has a more true-to-performance editing system.
editing and especially comping MIDI takes together reveals some of the problems of having MIDI item endpoints act as hard stops for notes that need to ring out/dangle. if there's another idea/answer to this issue than the dangle request, i'd love to hear it and i've been scripting what i can in the meanwhile.
|
we really need better options for this: "always split" is very restrictive, and while it works fine for griddy music, it really limits more nuanced/human MIDI performances.
Last edited by mccrabney; 12-14-2023 at 06:43 AM.
|
|
|
12-14-2023, 07:06 AM
|
#24
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
here, i demonstrate how we must use fixed lanes in order to accurately copy MIDI content: imagine duplicating large swaths of a project: REs stop being an easy "draw a box and copy-drag" to "draw a box, and then go through every MIDI track and make sure the right section of the fixed lanes are selected"
fixed lanes are awesome, but it seems like total overkill that we must use them in order to accurately duplicate real-world MIDI content:
if instead we had RE options to "include/exclude relevant note content outside of RE bounds," this would be easy.
|
|
|
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 09:40 AM.
|