Open ScottChesworth opened 2 weeks ago
I'm not exactly sure where the disconnect is here. However, as far as I understand it, you can't really have overlapping notes at the same pitch in MIDI. MIDI notes are defined by note on and note off messages. If you have a note on message at the same pitch, that just continues the note. If you then send a note off message, that ends the note. So, I guess REAPER (maybe even MIDI files) has a concept of overlapping notes, but when that gets sent to the instrument, they can't really overlap.
This is relevant because I'm wondering whether the REAPER API truncates the note end accordingly. The note does end at this point as far as the instrument is concerned, so perhaps the API exposes it thus. If that's the case, we're going to need some new API from Cockos to give us the raw length without truncation.
It's also possible that this truncation is happening somewhere inside OSARA. I don't think that's the case from a brief look at the code, but some of our length reporting code is a bit complicated, so I'm not ruling it out just yet. I need to dig a little more.
Note that if the subsequent notes are at different pitches, you don't hit this problem.
From my tests, the result comes from REAPER, technically from MIDI_GetNote API function.
Is that a bug or feature is unclear. Behind the scene, REAPER keeps full length, while reporting shorter length. So more bug then feature. But from musical perspective, the note will be shorter. MIDI does not prescribe to count MIDI On events for MIDI Off events, so after the first overlapping note ends, triggering MIDI Off, synths will stop playing both.
The effect is different if the first note ends before the second since the second MIDI On is send without MIDI Off, the synth can interpret that on its will. But once any overlapped note ends, all current notes will stop playing.
And so from that perspective, that is a feature which indicate maximal length the note is meaningful for the synth.
In case notes are not exactly the same, for example have different MIDI channels, REAPER reports full length.
Thanks for verifying, @AZSlow3. I suspected as much, but hadn't gotten to debugging it yet.
Regardless of whether it's a bug or feature of REAPER, it's a problem for us that the API exposes it differently to the UI. We'll probably need a new API function here (or perhaps a fix to the existing one, but Cockos probably won't do that because of the backwards compatibility risk).
As for UI, OSARA in fact reports more then GUI. In the example from Scott, visually there is no difference when the first note is expanded over following notes, it is hidden behind overlaps. Even when the note end is dragged by mouse.
But what sighted people notice easily is the fact the note is going to be overlapped. May be it is a good idea to add related feature into OSARA, I mean indicating a note is overlapping. As I have explained, the first overlapping may be desired, but any following overlapping will not work. I mean this issue comes from note manipulation which make no sense, currently users just don't have any hint there is a problem. If REAPER will report real length, that can be even more confusing then current issue since the sound will have currently reported length.
Hi, It does not happen for the subsequent notes with the same pitch only. In fact, I ran to this issue while trying to work with subsequent notes with different pitches. I'm dead sure this worked as expected before, But i can't verify wheather it's a Reaper or Osara issue.
I could not reproduce this with notes of different pitches. @Reza-JDP, if you are experiencing this, please provide exact steps to reproduce.
Steps to reproduce:
The expected behaviour is the note to be extended up to the edge of the item (or over its bounderies if set), But The result is The note length being announced incorrectly and getting stuck in a certain value.
You're absolutely certain that one of the other notes didn't have the same pitch? They don't all need to be the same pitch for this to occur. The first time you hit a note with the same pitch, that will cause overlapping to go weird.
Yes. I think that's the issue. When a note overlaps with another one with the same pitch, The problem occures. I'm checking with this project: grid problem.zip
In your project there are two first E4 notes. I mean two E4 starting at the beginning of the clip. That is definitively looking for troubles. All other notes have duplicates in the timeline, so when you increase the length you eventually overlap.
Well, we can report a bug to REAPER, from the change log I guess around 7.10 they have leaked auto-correction of overlapping notes when the option is off. I don't know how to reproduce without OSARA, it is only obvious once you make an overlap and then start navigating notes OSARA way. Along the road you can select a new note which was not there, which starts at the beginning of the overlap and ends at the end of the first overlapped note. If you move it, it become real, original two notes are auto-merged into one.
Or just turn on "Automatically correct overlapping notes". Then you should not hit related problems. Note you still can transiently move notes over existing, for example when creating chord inversion, but if you navigate away from the note which currently overlap, REAPER will fix the overlap.
The only reason to not auto-fix is when you use a synth which produce distinct sound when you overlap notes and that is desired effect. But I will not try to use such feature in real projects, till your usual live performance style is playing the same synth with two distinct keyboards, the only way to reproduce such behavior without MIDI editing.
@AZSlow3 That makes sense. I think it should be reported to Cockos though.
I have posted bug report: https://forums.cockos.com/showthread.php?p=2782973
From comments in the REAPER forum, it may take some effort to convince devs provide usable solution. Alternative approach is manipulating raw MIDI events instead of notes in OSARA. With potential difference between visual representation and audition, especially in a long term (if devs change behavior of the editor). Also before considering workaround, extra check should be done that automatic correction option is immediately mirrored in the events when on and not cached in the editor.
Thanks in advance for any tightening!