Yahoo Groups archive

The Logic Off Topic list

Index last updated: 2026-04-28 23:27 UTC

Message

Re: [L-OT] Understanding SYSEX

2001-04-19 by Hendrik Jan Veenstra

Thoughts from the mind of litepipe, 19-04-2001:

>  > As for what comes in the middle -- I really have absolutely no idea
>because
>>  it could be anything at all. It all depends on how Emu have decided to
>>  create a concert grand sound. Honestly and truthfully, decoding sysex data
>>  is a thorough pain in the neck. Those who do it like to protect their jobs
>>  by making it incredibly difficult to fathom what their up to.
>
>   See this is what I was trying to figure out. I thought that maybe there
>was some kind of standard or something.

There isn't, and there shouldn't be :-).  Sysex is specifically meant 
for transmission of vendor=specific information to hardware, so any 
standard would defeat the pupose.  And then... some synths have maybe 
50 parameters, while others may have 500, and maybe some future 
machine has 10000 parameters -- and the sysex protocol has to allow 
for all these old, current and future possibilities.  No standard 
could ever hope to achieve that.

Basically a Sysex message is a chunk of private lingo in the midst of 
a standardised (midi) language, as Kool Musick explained very cearly.

>I thought that it was more
>accessible than this. In my E-mu manual it says that set up parameters may
>be edited individually using system exclusive commands. The value of a given
>parameter may be changed by sending a parameter value command. That command
>happens to be F0 18 id dd 03 pl pm vl vm F7
>   It says pl =parameter # LSB  pm=msb vl=value lsb vm=msb
>   So then if I look in the chart for the preset parameters for say crossfade
>direction it says this: Parameter # 60   Then in a column under (H) it says
>(3C 00) and under parameter name it says crossfade directions. This is what
>I'm having a hard time piecing together.

Hang on -- sounds like you're almost there.  The id/dd bytes probably 
serve to identify your machine and will always be the same (except 
for possibly a midi channel specifier -- i.e. the id or dd could be 
e.g. anything between 00 and 0F (hex) indicating midi channels 1-16.
My Korg M1 has sysex that starts with 'F0 42 30 19...'  where the 0 
in 30 indicates the machine's midi channel.  So the meaning of the 
respective bytes is "start sysex", "Korg ID", "midi channel", 
"intended for an M1".  Your sysex format looks like it follows 
similar rules.

The interesting part is what follows next.  "03" probably means "here 
comes a parameter change" -- most likely various sysex functions have 
their own number, after which the machine knows what to expect next. 
The M1 (sorry to revert to this example, but that's the machine I 
know by heart and the format looks very similar) has functions for 
program dump, all programs dump, parameter change, global data dump, 
program write request, etc, etc.  So that gives a message that starts 
like
   F0 42 30 19 <function number> ...

The 4 bytes after seem that do the real job (as they do on the M1): 2 
bytes to specify the parameter and 2 for the parameter value. 
Apparently your manual lists parameter ordinals in decimal format, 
whereas you need them in Hex format.  The example you give, parameter 
60, is written in Hex as 3C: counting in base-16, the '3' means 3*16 
= 48.  And 'C' is '12', since the hexadecimal 'alphabet' goes "0 1 2 
3 4 5 6 7 8 9 A B C D E F", where A=10, B=11, etc.  And 48+12 = 60. 
Hey, presto! :-)

OK, so parameter 60 is 3C in hex, which fits in one byte (any two 
hex-numerals combined constitute exactly one byte, like F7 or 2A or 
whatever).  So the Least Significant Byte (LSB) is 3C, and the MSB = 
0.

Next you specify the value for the parameter in the following 2 
bytes, again in LSB/MSB order. So if you want to set the parameter 
value to 39, you would send a LSB of (hex) 27 (= 2*16 + 7) and a MSB 
of 0.  Your entire message would now look like

F0 18 id dd 03 3C 00 27 00 F7

... where you have to fill in the id/dd yourself.  If you're not sure 
what _they_ should be, hook up a monitor obejct to LA's Physical 
Input, and send some sysex to LA.  Easy as pie.



A complication that you should be aware of is the fact that the midi 
protocol only allows for 7-bit data bytes to be sent.  That means in 
practice that any data byte should be not 'above' 7F (hex).  7F (hex) 
= 127 (decimal) = 0111 1111 (binary) -- i.e. the highest number you 
can make without the topmost bit becoming 1 (since the next one, 80 
(hex) would be 1000 0000 in binary).

With some parameter values the 0-127 range will probably not be 
enough.  Hence the MSB for the parameter value (ditto for the 
parameter itself -- i.e. if you want to modify parameter 128 and up 
you'll run into the same problem).  That's where those MSB come in.
The most likely way tyo implement the LSB/MSB thing (although some 
manufacturers adopt strange ways of doing things) is to simply 
continue counting in the next byte.  So, with a LSB/MSB ordering, you 
would get:

decimal 127 = hex 7F 00
decimal 128 = hex 00 01
decimal 129 = hex 01 01
decimal 130 = hex 02 01
....
decimal 255 = hex 7F 01
decimal 256 = hex 00 02
decimal 257 = hex 01 02
......
and finally hex 7F 7F = decimal (127 + 127*128) = 16383 -- the 
highest you can get with 14 bits.
I.e. the MSB counts 'packets' of 128, while the LSB counts packets of 
'1'.  A small exercise: converting decimal 4567 to hex, we would get:
4567 = 35 * 128 + 87.  So MSB = 35 (dec) and LSB is 87 (dec).
Converting those to hex, we get: 35 = 2*16 + 3, hence 23-hex, and
87 = 5*16 + 7, hence 57-hex.
So LSB/MSB would be "57 23".


If the LSB/MSB are indeed implementred this way is something youhave 
to find out by experimentation.  Simply take parameter 128 (whatever 
that may be) and send "00 01" for the parameter LSB/MSB and see if 
indeed _that_ particular parameter is affected.


A similar problem holds when you have to send negative numbers (delay 
feedback = -87% for example).  Usually negative numbers are 
implemented as "counting backwards from the highest possible number". 
Since 7F 7F is the highest possible number, _that_ would mean "-1". 
Then 7E 7F is -2, 7D 7F is -3, etc.  A number sequence would then be:

decimal  hex (LSB/MSB)
...
-131     7D 7E
-130     7E 7E
-129     7F 7E
-128     00 7F
...
-4       7C 7F
-3       7D 7F
-2       7E 7F
-1       7F 7F
0        00 00
1        01 00
2        02 00
...
127      7F 00
128      01 01
129      02 01
...


OK, that's it for now.  This should get you going for the next day 
:-).  Have to get to work now...  Feel free to keep asking questions.


cheers,
Hendrik Jan
-- 
     Hendrik Jan Veenstra    ( h@... )

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.