|
|
|
03-30-2018, 02:08 PM
|
#1
|
Human being with feelings
Join Date: Apr 2010
Location: London (UK)
Posts: 412
|
Changing channel of a few notes deletes one (random, not always happening) (FIXED)
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
|
|
|
04-01-2018, 05:42 AM
|
#2
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
My first thought would be to check the MIDI editor's Event Filter.
|
|
|
04-01-2018, 11:15 AM
|
#3
|
Human being with feelings
Join Date: Apr 2010
Location: London (UK)
Posts: 412
|
hi! what should i look for in the event filter?
|
|
|
04-01-2018, 12:06 PM
|
#4
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
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.
|
|
|
04-01-2018, 01:19 PM
|
#5
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,821
|
Quote:
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.
|
|
|
04-01-2018, 03:27 PM
|
#7
|
Human being with feelings
Join Date: Apr 2010
Location: London (UK)
Posts: 412
|
Quote:
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
|
|
|
04-02-2018, 01:48 PM
|
#8
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
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:
Code:
+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:
Code:
+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:
Code:
+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)
|
|
|
04-02-2018, 03:15 PM
|
#9
|
Human being with feelings
Join Date: Apr 2010
Location: London (UK)
Posts: 412
|
Ouch my head hurts now! :-)
|
|
|
04-03-2018, 05:41 AM
|
#10
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,821
|
Quote:
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?
|
|
|
04-03-2018, 06:55 AM
|
#11
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
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.)
Last edited by juliansader; 04-03-2018 at 07:18 AM.
|
|
|
Thread Tools |
|
Display Modes |
Hybrid 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:12 AM.
|