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-21 by Hendrik Jan Veenstra

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

>   I should be setting up the output definition (not imput) if I want to send
>the message to my synth, right?

Yes.  But hold on -- basically there are two ways you can get sysex 
out of Logic. One is to use a sysex fader, and the other is to use a 
transformer that's set to 'sysex mapper'.  The former is easier at 
first, but the latter appears to be more flexible.

>   From what my E-mu manual says (concerning the value box inside the SYSEX
>fader beneth the checksum box) that it uses LSB/MSB format. Do I have to put
>a setting in the checksum box also? I believe my setting is supposed to be
>2's com.
>   As for the position parameters, I'm lost. The message I'm trying to send
>in Hex is F0 18 08 00 03 17 00 12 00 F7. The 12 being the part I want to
>control with the fader. What should I set it too?

OK, let's work this example out in 2 directions: sysex fader and 
sysex transformer.  The fader first.


Chapter 1: sysex faders

If you open the fader's window (out-definition set to sysex of 
course), you'll be able to adjust the sysex-message length by 
clicking on the < and > symbols left and right of the F7.  It seems 
that the default length happens to be correct in your case, so leave 
it alone
Then enter data such that the message looks like

F0 18 08 00 03 17 00 12 VAL F7

If the message is selected, you'll see the above.  Now click above 
the message on the "Start of List" line to deselect it, and you'll 
see it change to

F0 18 08 00 03 17 00 12 00 F7

I.e. the VAL has changed to 00. The VAL thing is exactly the byte 
which the fader will modify when you drag it.  In this case however, 
it's in the wrong position: your LSB-value is where the '12' is, and 
not the byte after that.  In order to change this, select the message 
again, and from the 'Position' popup (bottom left in the window) 
select "last-1".  You should now see

F0 18 08 00 03 17 00 VAL 00 F7

Now *with the message still selected* close the window.  You're done: 
dragging the fader from 0 - 127 should send out sysex messages from

F0 18 08 00 03 17 00 00 00 F7
to
F0 18 08 00 03 17 00 7F 00 F7

The important part here is keeping the message selected: that's the 
only way the VAL-thing is displayed, and hence the only way you can 
modify the message by dragging the fader.
The idea is that you could include e.g. 3 messages in the fader, and 
have only the second and third be affected by dragging, while the 
first remains constant (achieved by selecting the 2nd and 3rd, while 
deselecting the 1st, before closing the window).
Aside: this gives a whole bunch of new applications for the sysex 
fader.  You could e.g. insert 16 "volume = 127" messages on 16 midi 
channels in the fader.  Deselect them all, and close the window.  Now 
any fader movement will send out 16 "volume = max" messages, 
instantly resetting all your gear's volume to maximum.  No sysex is 
used here, despite the fact that it's a sysex fader :-).  Thinking 
this example through, you'll see that this indeed is a potentially 
very useful and flexible application of sysex faders -- something you 
would not be able to achieve conveniently in any other fashion.

Oh, and keep the checksum popup to "off", except when your manual 
explicitly tells you that sysex messages should be closed with a 
checksum message (which I don't suppose is the case, judging from 
your previous posts).

NOTE: if you ever want to automate these sysex faders: no-go.  Since 
Logic sucks at sysex handling, you can't properly record sysex faders 
without running into all sorts of trouble.  Automation _can_ be done 
by a workaround: change the sysex fader's in-definition to something 
little used, like controller-80.  Now create a fader whose in & out 
definitions are cc-80.  Connect its output to your sysex fader.  Move 
the sysex fader off-screen (you don't use it for dragging anymore, 
but just for transforming cc80 to sysex), and use the cc80 fader for 
sending sysex, recording and playback.
If you have 20 sysex faders, do something similar: every sysex fader 
should have it's own in-definition (e.g. cc80 to cc99), and should be 
connected to a controller fader with corresponding in/out 
definitions.  Then connect one (default, i.e. no settings applied) 
transformer or monitor object to all 20 cc faders, and assign that 
one to a track.  Now recorded data in the cc80 - cc99 range on that 
track will, through the transformer/monitor, reach your controller 
faders, which in turn will forward the message to the offscreen sysex 
faders.  Setup & idea similar to the channel splitter trick used on 
audio objects.  The order of connection is thus:
transformer -> 20 controller faders -> 20 sysex faders


Chapter 2: achieving the same thing with a transformer.

Create a new transformer, double click to open its window, and set 
its mode of operation to "Sysex mapper".  Since your sysex message 
will be 10 bytes long (counting F0 and F7), change the "sysex length" 
parameter to 10.  Now edit all values, until it looks like

F0 18 08 00 03 17 00 00 00 F7

Now you want to be able to change dynamically the 7th byte (counting 
now ignores the first byte (start of exclusive)).  So what you should 
do is connect a controller-7 slider to the transformer: the 
controller number (-1- value) determines _which_ byte will be 
changed, while the value (-2- value) determines the value to which 
the changed byte will be set.
So in this case: create a new fader.  The default fader already is 
cc7, so that's handy.  Connect it to the transformer.  Now have the 
transformer window open next to the environment window (so you can 
see the sysex message and the fader at the same time).  Drag the 
fader and watch the message: presto.
Try changing the fader's out definition to cc8, and see what happens: 
the next byte (sysex value MSB, in this case) will be modified.  Etc.

Automation again is sort-of tricky.  You could simply record the 
fader movement, assign a track to the fader and play back the data 
you recorded on that track.  However, recording the fader will record 
cc7 data, which normally is 'volume'.  This might be confusing.  And: 
you might have a bunch of sysex transformers with faders, all 
modifying the 7th byte (all modifying the value of a _different_ 
synth-parameter but the value byte is always in the 7th position), 
and thus all faders would send out cc7 data.  In order to automate 
those, you would have to assign seperate tracks to seperate faders, 
which is messy and clumsy.
The solution is similar to the solution in the sysex-fader case: if 
you have e.g. 10 such fader/transformer combo's, set the fader's 
in-definitions to e.g. cc's 80 to 89 respectively.
Create 10 new faders, whose in _and_ out definitions are set to cc's 
80-89 respectively, and hook them up to the 10 old faders.  Connect a 
transformer or monitor to the 10 new faders.  Use the 10 new faders 
for recording.  Assign a track to the transformer/monitor, and put 
your automation data on that track.  So it looks like this:

              +->  fader in=80, out=80 --> fader in=80, out=7 --> sysex mapper
transformer -+->  fader in=81, out=81 --> fader in=81, out=7 --> sysex mapper
              +->  fader in=82, out=82 --> fader in=82, out=7 --> sysex mapper


The obvious advantage of using a sysex mapper instead of a fader, is 
that a sysex mapper allows you to determine 'on the fly' which byte 
to modify, whereas a fader requires you to determine this while 
setting up the fader.  And, even more importantly, a sysex mapper 
allows you to modify more than one byte, which is not possible with a 
sysex fader.
This last point is especially important when dealing with values that 
also use the MSB of the value LSB/MSB combo -- i.e. values that 
exceed the 0-127 value range (like 0-200, or -99 - +99).  Those are 
quite common, as you will realise, so it might be a good idea to use 
sysex mappers instead of faders from the onset.


Chapter 3: 14 bit faders

A more complicated situation: suppose your synth represents negative 
numbers the way I outlined in my previous post -- i.e. MSB/LSB = 
7F/7F means -1, 7F/7E means -2, etc. (See previous post for details). 
You now want a fader with a range from -99 to +99, and connect a 
sysex mapper to that, in such a way that the proper data is sent to 
your synth.
That means 1) your fader has to have a range that exceeds 128 values, 
and 2) you have to modify 2 bytes in the sysex message simultaneously.
It will be clear that this is _much_ more involved than the previous 
situation in which a 'decent' 0-127 value range was used.  Describing 
how to do this efficiently would require another few pages.  I don't 
mind writing them, but not until I know that you have use for such 
information (after all, I _do_ have a life :-).

So for now: try to get the 'simple' situation working first.  If you 
want me to explain how to send 14bit values, just ask again.  In that 
case, please try to pick a complicated example, like a parameter that 
has a +/- 200 value range, and try to find out how negative numbers 
are represented (good chance that the format is indeed as I described 
in my previous post).  Then at least I'll know I won't describe a 
non-relevant situation.

>Please excuse me if it seems like I'm trying to get you to do all the work
>for me. I've been trying to get this worked out for many, many weeks. It
>just hasn't been the kind of thing that I've been able to stumble on through
>experimenting.

No problem.  This stuff _is_ complicated, especially when you're new 
to sysex, hex notation and such.  I'm rather fluent when it comes 
down to talking sysex, programming in general, and I know my synths 
inside out, and even I had to spend several frustrating days trying 
to figure this all out.  So, feel free to ask any more questions 
(that will surely arise :-)


cheers,
HJ
-- 
     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.