|
|
|
01-15-2010, 11:50 AM
|
#1
|
Human being with feelings
Join Date: Dec 2009
Posts: 50
|
State Chunk. RPP File MIDI Format. Field 1: X/x instead of E/e
State Chunk and RPP File MIDI Format.
It's really exciting that in Reaper 3.2, the Max Length of a string returned by GetSetItem State has been increased to 1MB.
I've been working with the strings returned from Midi Items, and found something I don't understand in field 1.
As described here:
http://www.cockos.com/wiki/index.php...dRppMidiFormat
...typically the first field is an Upper case 'E' or lower case 'e' if the event is selected. I've noteced that in reaper 3.2, sometimes My midi off events have an upper or lower case 'X' in Field 1. Resizing the midi note and calling GetSetItemState again changes Field 1 back into an 'normal' line (one with an E at the beginning and 5 fields total)
an exerpt for example:
HASDATA 1 960 QN
E 0 90 3e 02
X 480 0 80 3e 00 4294966816 1127286911
E 480 90 43 03
X 480 0 80 43 00 4294965856 1127286911
e 480 90 3e 7f
e 960 80 3e 00
E 0 90 41 7f
E 960 80 41 00
The first two Note off events have an X in the first field and three additional fields (fields 3, 7, and 8). The values in fields 3 7 and 8 seem to always have the same values. has anyone else experienced this? does anyone have an idea what the X might represent?
I'm trying to use GetSetItemState To automate midi editing Similar to Sonar's Cal scripting. So it's important that I understand very precisely how midi events are represented.
I'm calling GetSetItemState from python
Last edited by AudiOishi; 01-15-2010 at 11:52 AM.
Reason: adding additional info
|
|
|
01-15-2010, 12:04 PM
|
#2
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
The usual format for a note is
state tick_offset hex1 hex2 hex3 [prequantized_offset]
where state can be
e = note
E = selected note
em or Em = muted note
prequantized_offset, if it exists, is the difference between the note's position and where its position was before it was quantized.
If the tick_offset or prequantized_offset would be larger than 2^32 (about 4 billion ticks), then an alternate format is used:
state tick_offset1 tick_offset2 hex1 hex1 hex3 [prequantized_offset1 prequantized_offset2]
using x instead of e, and the actual offset is (offset1)|(offset2<<32).
In your particular example, assuming you didn't quantize the "X" notes by about 100,000 hours, the very high prequantized offsets are probably garbage coming from something being uninitialized. You could parse the X notes just like E notes and throw away the offset2 numbers. We'll look into what might be causing the uninitialized numbers.
|
|
|
01-16-2010, 04:13 AM
|
#3
|
Mortal
Join Date: Dec 2008
Location: France
Posts: 1,969
|
woo! thanks schwa!!
|
|
|
01-16-2010, 11:36 AM
|
#4
|
Human being with feelings
Join Date: Dec 2009
Posts: 50
|
Wonderful. Thanks! I'll add this info to the wiki too.
|
|
|
01-16-2010, 03:33 PM
|
#5
|
Human being with feelings
Join Date: Dec 2006
Location: UK
Posts: 789
|
Thanks schwa.
So X and x messages then - I thought they were sysex messages, they're notes?
__________________
Mike Lacey, Leicestershire, UK
|
|
|
01-16-2010, 03:56 PM
|
#6
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Messages in the format AudiOshi posted are "extended" notes as described above (though again, in this case it's clear the "extended" prequantized offset is an error and they can be treated just like regular notes).
Sysex, text, and other meta-messages will have the format:
<X tick_offset1 tick_offset2 base64_string>
... note the enclosing < > characters.
|
|
|
01-16-2010, 05:07 PM
|
#7
|
Human being with feelings
Join Date: Dec 2006
Location: UK
Posts: 789
|
Ok, cheers schwa [Mike scurries off to the Wiki]
__________________
Mike Lacey, Leicestershire, UK
|
|
|
01-17-2010, 02:45 PM
|
#8
|
Human being with feelings
Join Date: Dec 2006
Location: UK
Posts: 789
|
Hey AudiOishi, I don't know if you're "watching" it but I've answered you on that page's discussion page.
__________________
Mike Lacey, Leicestershire, UK
|
|
|
11-16-2016, 06:47 PM
|
#10
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
There seems to be an error on the StateChunkAndRppMidiFormat wiki page: It states that
Quote:
When the first character of a line is an X or x, the number of midi ticks between this midi event and the previous midi event are encoded as the sum of tick_offset1 and tick_offset2
|
but this should probably read "sum of tick_offset1 and (tick_offset2<<32)".
Last edited by juliansader; 11-17-2016 at 05:59 AM.
|
|
|
11-17-2016, 09:09 AM
|
#11
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by schwa
If the tick_offset or prequantized_offset would be larger than 2^32 (about 4 billion ticks), then an alternate format is used:
state tick_offset1 tick_offset2 hex1 hex1 hex3 [prequantized_offset1 prequantized_offset2]
|
Also important to mention in the wiki, is that offset1 (and its prequantized offset1) are represented as unsigned 32bit integers. A negative offset is converted to 4294967296 (2^32) minus the number:
-1234 => 4294966062
Questions for schwa:
* Will the extended format will be used if the offset is larger than (2^32) / 2?
* Are there any limits on the size of offset2? (Will it ever be larger than 1 digit?)
* Is negative offset2 also represented as an unsigned integer, or will it represented with a minus sign?
|
|
|
11-17-2016, 01:22 PM
|
#12
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Quote:
Originally Posted by juliansader
Will the extended format will be used if the offset is larger than (2^32) / 2?
|
2^32-1 (0xFFFFFFFF).
Quote:
Originally Posted by juliansader
* Are there any limits on the size of offset2? (Will it ever be larger than 1 digit?)
|
no limit (though as a practical matter you would need a ridiculously long file with a ridiculously high MIDI resolution for offset2 to be greater than zero in the first place).
Quote:
Originally Posted by juliansader
* Is negative offset2 also represented as an unsigned integer, or will it represented with a minus sign?
|
Offsets are always positive.
|
|
|
11-17-2016, 02:47 PM
|
#13
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by schwa
Offsets are always positive.
|
I am not sure that this is correct? When MIDI is unsorted, or when an event has been quantized to the left, the offsets and pre-quantized offsets can be negative.
For example, in AudiOishi's original post, the "4294966816" means that the event has been quantized to the left with
2^32-4294966816 = 480 ticks.
|
|
|
11-17-2016, 03:20 PM
|
#14
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
The OP is from 6 years ago -- the quantization offset may have been saved in an awkward signed/unsigned method at that time.
The regular offset (the number of MIDI ticks between this event and the previous event) is always positive (er, non-negative). offset1 holds offset&0xFFFFFFFF (2^32-1) and offset2 holds offset>>32 if the offset is indeed that large.
The quantization offset (the number of MIDI ticks between the quantized position of this note and its unquantized position) can be positive or negative. If the offset is between -2^30 and 2^30 (exclusive) then offset1 is stored as a single signed integer. In the exceedingly insane case where an event is quantized 2^30 or more ticks away from its unquantized position, the quantization amount will be stored in the same way as offset1 and offset2 above, which may end up storing/restoring a negative value as a pair of unsigned integers, but really if you are quantizing notes that far the best thing to do is just set fire to your computer anyway.
Backwards compatibility is likely maintained, so the unsigned storage of a negative quantization offset in the OP is probably loaded properly in the current version of REAPER. If you then save the project immediately, it should be stored as a single negative integer.
Last edited by schwa; 11-17-2016 at 03:36 PM.
|
|
|
11-17-2016, 03:53 PM
|
#15
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
I use as an example a take with only two MIDI events: an unselected CC at 1920 and a selected CC at 3840 ticks. I then run MIDI_SetCC with the noSort option to move the selected CC to the left of the unselected one:
reaper.MIDI_SetCC(take, 1, nil, nil, 0, nil, nil, nil, nil, true)
The Raw MIDI display shows a negative offset:
+1920 1920: B0 0B 6C
+-1920 0: B0 0B 6B
+32640 32640: B0 7B 00
When I load the item's state chunk with reaper.GetItemStateChunk and then display it with reaper.ShowConsoleMsg, I get:
E 1920 b0 0b 6c 240
e 4294965376 b0 0b 6b
E 32640 b0 7b 00
|
|
|
11-17-2016, 03:59 PM
|
#16
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Well, that's a corner case. I don't think there's any way to have unsorted MIDI in a saved project unless you're altering MIDI via API, and the best practice would be for the API to sort MIDI when necessary.
|
|
|
Thread Tools |
|
Display Modes |
Linear 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 06:20 PM.
|