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@... )Message
Re: [L-OT] Understanding SYSEX
2001-04-19 by Hendrik Jan Veenstra
Attachments
- No local attachments were found for this message.