Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using "Edit: Lengthen notes one grid unit" or "Edit: Shorten notes one grid unit" actions in the piano roll, OSARA reports adjustments incorrectly if the note being adjusted overlaps more than one other note #1078

Open
ScottChesworth opened this issue May 14, 2024 · 14 comments
Assignees
Labels
bug midiEditing MIDI Editor, Piano Roll, event list, notation, etc. needsReaperFix p1 High priority.

Comments

@ScottChesworth
Copy link
Collaborator

  1. Insert a blank MIDI item, select it and open the piano roll (Control+Alt+E).
  2. Set grid to 16th notes (CONTROL+Shift+6), set length of next inserted note also to 16 (Control+6).
  3. at bar 1 beat 1, press I to insert a single note. Then press page down to jump to bar 2 beat 1, and press Shift+I a bunch of times to insert a contiguous run of 16th notes.
  4. Now select the first note you inserted, use NumPad3 or L to start extending its length by grid unit.
    Expected: OSARA should report each extension of note length in 25% increments seeing as we're set to a 16th note grid. I'd expect this to happen consistently either until the note reaches the right edge of the MIDI item or perhaps beyond, depending on local settings.
    Actual: OSARA reports the first 4 extends fine "50%, 75%, 1 beat, 1 beat 25%". However, this is where we reach overlapping with more than one other note. Keep hitting NumPad3 or L, you'll hear that OSARA continues to report "1 beat 25%" forever. You can verify that the length of the note is extending using REAPER's Event Properties dialog (Control+F2).
  5. Extend the length of the first note far enough that it's overlapping a handful of subsequent notes, then try NumPad1 or Shift+L to shorten the note 1 grid unit.
    Expected: OSARA should report the note length as retracting in 25% increments, matching what we find in REAPER's Event Properties.
    Actual: OSARA will report "1 beat 25%" until overlapping a single note, then reporting resumes as expected, in this case a single accurate report of "1 beat 25%", then "1 beat, 75%, 50%, 25%".

Thanks in advance for any tightening!

@ScottChesworth ScottChesworth added bug p1 High priority. midiEditing MIDI Editor, Piano Roll, event list, notation, etc. labels May 14, 2024
@jcsteh
Copy link
Owner

jcsteh commented May 14, 2024

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.

@jcsteh
Copy link
Owner

jcsteh commented May 14, 2024

Note that if the subsequent notes are at different pitches, you don't hit this problem.

@AZSlow3
Copy link
Contributor

AZSlow3 commented May 14, 2024

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.

@jcsteh
Copy link
Owner

jcsteh commented May 14, 2024

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).

@AZSlow3
Copy link
Contributor

AZSlow3 commented May 14, 2024

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.

@Reza-JDP
Copy link

Reza-JDP commented May 14, 2024

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.

@jcsteh
Copy link
Owner

jcsteh commented May 14, 2024

I could not reproduce this with notes of different pitches. @Reza-JDP, if you are experiencing this, please provide exact steps to reproduce.

@Reza-JDP
Copy link

Steps to reproduce:

  1. Incert a midi item.
  2. Open midi editor and set grid size to 1/16.
  3. Use step recording to add notes. For example: e 4 g# 4 b 4 e 5 b 4 e 5 b 4 g# 4 e 5 g# 4 b 4 e 5 b 4 e 5 b 4 g# 4.
  4. Select the first note (In this case, e4).
  5. Use numpad 3 to extend it.

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.

@jcsteh
Copy link
Owner

jcsteh commented May 15, 2024

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.

@Reza-JDP
Copy link

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

@AZSlow3
Copy link
Contributor

AZSlow3 commented May 15, 2024

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.

@Reza-JDP
Copy link

@AZSlow3 That makes sense.
I think it should be reported to Cockos though.

@AZSlow3
Copy link
Contributor

AZSlow3 commented May 15, 2024

I have posted bug report: https://forums.cockos.com/showthread.php?p=2782973

@AZSlow3
Copy link
Contributor

AZSlow3 commented May 21, 2024

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.

@ScottChesworth ScottChesworth self-assigned this May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug midiEditing MIDI Editor, Piano Roll, event list, notation, etc. needsReaperFix p1 High priority.
Projects
None yet
Development

No branches or pull requests

4 participants