Changing channel of a few notes deletes one (random, not always happening) (FIXED)

[tusitala]

Hi, I can't reproduce this all the time but somehow it's happening in my current project.

I select a few notes and using a shortcut I assign them to a different midi channel (as I do quite frequently)

Any insight?

I'm on the latest official Reaper release, MacOS 10.13.3

[juliansader]

My first thought would be to check the MIDI editor's Event Filter.

[tusitala]

hi! what should i look for in the event filter?

[juliansader]

If the Event Filter is the problem, it would display "Show only events that pass filter" checked, with some or other combination of filter settings.

If the Event Filter isn't the problem, you could perhaps find out where the missing note went to by checking View -> Raw MIDI data, or by using the MIDI Inspector script.

[schwa]

Originally Posted by tusitala

I select a few notes and using a shortcut I assign them to a different midi channel (as I do quite frequently)

Are you changing the notes to the same channel as the immediately previous notes? If so, and the first changed note overlaps with the one before it, and the MIDI editor option "automatically correct overlapping notes" is enabled, that might explain this behavior.

[juliansader]

Ah yes, now I remember this bug has been discussed at length before.

Also related: Pasted note disappears if it overlaps existing note.

Poor abandoned piano roll, hungry and alone, looking at all the fancy new features that are getting all the devs' love.

[tusitala]

Originally Posted by schwa

Are you changing the notes to the same channel as the immediately previous notes? If so, and the first changed note overlaps with the one before it, and the MIDI editor option "automatically correct overlapping notes" is enabled, that might explain this behavior.

Dear Schwa,
Thank you very much for your help...I think you nailed it and that’s exactly what happens, as I managed to reproduce this behaviour in a new and empty project.
I wasn’t aware of the “automatically correct overlapping notes” option, and yes, if I deactivate it, this behaviour doesn’t happen again.

What’s strange tough is that I inputted those notes using “step recording” so their value is supposed to be perfectly quantised and I assume that because of that they should not be overlapping...am I wrong or am I missing something?

Thanks a lot again for your work.
All the best
-t

[juliansader]

Originally Posted by tusitala

What’s strange tough is that I inputted those notes using “step recording” so their value is supposed to be perfectly quantised and I assume that because of that they should not be overlapping...am I wrong or am I missing something?

REAPER stores MIDI data as a sorted sequence of events (which you can inspect with View -> Raw MIDI data). In the case of MIDI events that fall on the exact same tick position, events on lower channels are sorted before those on higher channels.

When two perfectly quantized notes are adjacent, the first note's note-off falls on the same tick position as the next note's note-on, so the MIDI data looks like this:

+0     0:        91 30 60     (Note 1 note-on, channel 1)
+960   960:      90 30 60     (Note 2 note-on, channel 0)
+0     960:      81 30 00     (Note 1 note-off, channel 1)
+960   1920:     80 30 00     (Note 2 note-off, channel 0)

If the second note's channel is changed to 1 -- and if REAPER neglects to re-sort the events on tick 960 -- you get:

+0     0:        91 30 60     (note-on, channel 1)
+960   960:      91 30 60     (overlapping note-on, channel 1)
+0     960:      81 30 00     (note-off, channel 1)
+960   1920:     81 30 00     (note-off, channel 1)

Now there appears to be an overlapping note on channel 1.

To avoid triggering "Correct overlapping notes", REAPER should sort the MIDI events on tick 960 before correcting:

+0     0:        91 30 60     (Note 1 note-on, channel 1)
+960   960:      81 30 00     (Note 1 note-off, channel 1)
+0     960:      91 30 60     (Note 2 note-on, channel 1)
+960   1920:     81 30 00     (Note 2 note-off, channel 1)

[tusitala]

Ouch my head hurts now! :-)

[schwa]

Originally Posted by juliansader

In the case of MIDI events that fall on the exact same tick position, events on lower channels are sorted before those on higher channels.

I don't think that's correct. REAPER goes to some effort to keep MIDI events in a stable order, to avoid endless problems like this, with drum-triggered notes of zero length, etc. There shouldn't ever be an arbitrary sort on some attribute other than time position.

Do you have a sequence of events that causes notes to be sorted in the order you are showing?

[juliansader]

Originally Posted by schwa

There shouldn't ever be an arbitrary sort on some attribute other than time position.

Do you have a sequence of events that causes notes to be sorted in the order you are showing?

In the case of events that fall on the same time position, I assume that some other attribute is taken into account?

This image shows how note-ons and note-offs at PPQ position 960 are sorted by channel:



(Similarly for pitches, CCs etc of the same type, on the same PPQ position.)

[Bri1]

This image shows how note-ons and note-offs at PPQ position 960 are sorted by channel:

Is that not logical? keeping order of channels?
How about some type of automatic 'offset' where no 2 notes are 'allowed' to share an exact space- moving by 1 tick either way,for 'human'ness' .. ?
This helps to reduce audio transients overloads also eh....

[schwa]

Originally Posted by juliansader

In the case of events that fall on the same time position, I assume that some other attribute is taken into account?

This image shows how note-ons and note-offs at PPQ position 960 are sorted by channel:

The order should just be the order the events were added, in other words the order the notes were created.

[juliansader]

Here is the same sequence of actions on my system:

[schwa]

Well, something is different there!

Do you have any extension installed that might be reacting to changes in the MIDI item? That is in-project MIDI, right?

[juliansader]

I quickly checked the same actions on a new portable install without any extensions, and I get the same behavior.

I have always thought that sorting by channel is the normal behavior, and have discussed it long ago in other bug report threads too.

(MIDI is in-project.)