Old 09-06-2016, 03:02 AM   #1
Lostz
Human being with feelings
 
Lostz's Avatar
 
Join Date: May 2012
Location: Italy - Austria
Posts: 52
Default SetNote Bug on Not Overlapping Notes? (FIXED)



Code:
editor = reaper.MIDIEditor_GetActive()
take   = reaper.MIDIEditor_GetTake(editor)
if take then

  reaper.Undo_BeginBlock2(0)

  i = reaper.MIDI_EnumSelNotes(take, -1)
  while i ~= -1 do
      retval, sel, _, _, _, _, _, _ = reaper.MIDI_GetNote(take, i)
      if retval and sel then
          reaper.MIDI_SetNote(take, i, nil, nil, nil, nil, nil, nil, 15, true)
      end
      i = reaper.MIDI_EnumSelNotes(take, i)
  end
  reaper.MIDI_Sort(take)

  reaper.Undo_EndBlock2(0, "Set Fixed Velocity pp", -1)
end
Win7 x64, Reaper 5.24/x64
__________________
Thanks.

Last edited by juliansader; 09-19-2016 at 04:39 AM.
Lostz is offline   Reply With Quote
Old 09-06-2016, 09:38 AM   #2
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 2,604
Default

Thanks for the report! I can confirm that I have also encountered behavior such as this before. The bug may be related to ReaScript: Using MIDI_SetNote with noSort=true to move notes onto same pitch, which also involves non-overlapping notes becoming extended.

ReaScript bugs such as these are particularly nasty since they undermine users' confidence in ReaPack scripts, as discussed in the thread Reaper for Orchestral work.
juliansader is offline   Reply With Quote
Old 09-16-2016, 08:59 PM   #3
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 2,604
Default

This may have something to do with notes ending in Note-Ons with velocity=0 instead of normal Note-Offs, as reported in:

ReaScript: MIDI_Sort extends non-overlapping notes that end in Note-Ons with vel=0.

juliansader is offline   Reply With Quote
Old 09-17-2016, 06:02 AM   #4
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,197
Default

Hmm I can't duplicate this (even with projects with 0x90-style noteoffs). Can someone post a test project and reaper.ini?
Justin is offline   Reply With Quote
Old 09-17-2016, 09:08 AM   #5
Lostz
Human being with feelings
 
Lostz's Avatar
 
Join Date: May 2012
Location: Italy - Austria
Posts: 52
Default

Thanks.
https://stash.reaper.fm/28509/REAPER.ini
https://stash.reaper.fm/28508/midi_broken_2.RPP

Win7 x64, Reaper 5.24/x64
__________________
Thanks.
Lostz is offline   Reply With Quote
Old 09-17-2016, 09:24 AM   #6
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 2,604
Default

Ah, your MIDI does indeed contain many Note-On endings. In particular, the note that becomes extended in your GIF has the MIDI data
+23977 23977: 96 35 62
+936 24913: 96 35 00

As Justin noted, the culprit may be MIDI_Sort instead of MIDI_SetNote: In your project, MIDI_Sort alone is sufficient to cause the extended notes. In my own bug report on MIDI_SetNote, I also combined that function with MIDI_Sort.
juliansader is offline   Reply With Quote
Old 09-17-2016, 09:43 AM   #7
Lostz
Human being with feelings
 
Lostz's Avatar
 
Join Date: May 2012
Location: Italy - Austria
Posts: 52
Default

Step by step what I did:
* I've imported a MIDI,
* then arranged for piano,
* exported directly from the MIDI Editor,
* and then finally imported into another project.

If you write the notes directly in the MIDI Editor it doesn't happen.
__________________
Thanks.
Lostz is offline   Reply With Quote
Old 09-17-2016, 10:02 AM   #8
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 2,604
Default

MIDI that is recorded live often contains Note-On ends instead of Note-Offs. There is a nice post at KVR that describes the reason: 0 velocity note on = note off?

Quote:
There's a thing in MIDI called "running status". Normally a MIDI message consists of a status byte (which always begins with the high order bit set to one: 1xxxxxxx), followed by 2 data bytes (which always have the high order bit set to zero: 0xxxxxxx).

The status byte is used to describe the type of message, there's one code for note-on, another for note-off, another for control change, etc...

Then the first data byte describes WHICH control or note has been changed. i.e. the CC# or the note #. Because we never use the high-bit, we get a range of 0 - 127.

And the second data byte describes the position of the control or the velocity of the note. Again we have a range of 0 - 127 (however for note velocities, zero is reserved to mean note off because...)

If a whole bunch of messages come through, all for the same status, MIDI has the ability to save a some bandwidth by leaving out the status byte. This is called "running status". And obvious use for it is when performing a control change, you can save 1/3 of the traffic on the MIDI cable by only sending the status byte at the beginning of the stream (note that this works only as long as the stream isn't interrupted by any other type of message status. As soon as another type of message comes through, the running status is broken).

And to take advantage of this for note data, a stream of note-ons and note-offs can be differentiated by the velocity value in the 2nd data byte, without needing to send a new status byte every time your performance switches from note-on to note-off.

So by the MIDI spec, you are required to treat a note-on with zero velocity exactly the same as you would a note-off.


Make sense? (Even I forgot the reason for this until a recent VST list discussion reminded me. )
EDIT: MIDI_Sort FIXED in v5.25rc2!

Last edited by juliansader; 09-19-2016 at 04:41 AM.
juliansader is offline   Reply With Quote
Old 09-19-2016, 10:48 PM   #9
Lostz
Human being with feelings
 
Lostz's Avatar
 
Join Date: May 2012
Location: Italy - Austria
Posts: 52
Default

Thanks guys!
I'm going to update my signature.
__________________
Thanks.
Lostz is offline   Reply With Quote
Old 09-20-2016, 12:19 AM   #10
ELP
Human being with feelings
 
Join Date: Apr 2014
Posts: 943
Default

"There's a thing in MIDI called "running status"."

A few practical example for the timing differences eyes :

Standard theoretical 31250 Baud
1 MIDI transmission byte = 8 bit + Start and Stop bit = 10 bit
31250:10 = 3125 transmission bytes
1 transmission byte in ms = 1000 ms : 3125 tb = 0.32 ms
=3 byte event messages need = 0.96 ms

Control Change events| the same Controller and Channel
5000 Control Changes

Standard good MIDI Device:

without running need:
5000 #cc * 0.96 ms = 4800 ms

with running enable
5000 #cc need
4999 * 0.64 ms + 1 * 0.96
=~ 3200 ms

5000 Control Change events | the same Controller Nr. and Channel

Standard working good Device:

4800 ms vs 3200 ms
= these 5000 control changes events would arrive 1600 ms earlier. 1.6 seconds!!

Bad MIDI Device work within this range:
5500 ms vs 4000 ms

Exzellent working MIDI Devices ~ :
4500 ms vs 3000 ms

If possible running can make a huge difference for the timing;
and this do not refers only for MIDI DIN
with USB and CO, it is the same.
__________________
I hope you can understand me? Without german beer my written english is always very bad, with beer it becomes unbearable!.
Less is more! To much limited the own creativity.
ELP is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:37 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.