Hi, I have a specific question, or rather a problem:
For a particular application, I want to process only the individual bytes of Sysex messages - specifically, everything that occurs between (Hex) F0 and F7 - as individual events.
My plan was to create two presets: Preset 1, in which a translator reacts to F0 and thereby activates Preset 2, which then processes all the Sysex bytes until F7 is reached, at which point a second translator in Preset 1 deactivates Preset 2 again.
This way, I would only have the Sysex bytes between F0 and F7 available in Preset 2, because whenever the Sysex is over, it turns off and turns back on at F0.
Now, the problem I’m running into: a single F0 or F7 isn’t enough as a predefined trigger - nothing happens. A trigger is apparently only triggered by complete Sysex messages, which must also match the length of the incoming command. There can be variables in between, but the length is fixed. However, I’d like to “separate” all Sysex messages, so the length requirement is a hindrance, because they can be VERY different and also very long.
How can I work around this? Am I missing something? Is there any way to use individual F0 and F7 bytes (as raw MIDI bytes) for triggering?
Admittedly, this is a very specific request…
Thanks!
In place of the bytes you do not want to change, just either enter the bytes (in hexadecimal) or a variable as a pattern for the input and then use the same value for that byte for the output. It is always better to use local variables if possible but there are only 10 of them. If using global variables, then care must be taken to ensure more than one translator’s input pattern is not used at the same time.
For example
Input Raw: F0 02 59 3F 54 oo F7
Rules:
Change the value of oo to something else
Output : F0 02 59 3F 54 45 F7
where 45 replaces in input value of oo in the above pattern
The output does not need to be Raw. You can use the bytes as for any type of outgoing messages.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Thanks, Steve,
I think I described it wrong - sorry… the correct term would have been “EVERY BYTE of the Sysex messages”, “individual” was the wrong word (sorry, it’s not my native language).
The goal is to build a kind of monitor specifically for Sysex strings.
It’s a bit of a gimmick, but it could also be practically useful for me.
I have a tiny little monitor that I can control with the Retrokits RK002 Cable, which runs a converter from MIDI notes to ASCII characters. Depending on the note played, the monitor then displays letters and numbers, like a typewriter, until it’s full, then it scrolls on.
Once I have all the individual Sysex bytes, I want to convert them into the appropriate notes (or note pairs), and if the whole thing runs on an interconnected BomeBox, I’d essentially have a small standalone MIDI monitor that displays Sysex (I could do this for other data too, but I’m not that interested in it - I just want to see Sysex). I think that would be handy, for example, when editing MIDI controllers for synths, etc…
Full bulk dumps it don’t make sense here, but individual Sysex commands fit on the monitor.
Like I said, just a bit of fun and a scripting exercise
I know there are other ways to do this, but I wanted to try it this way since I have all the tools here.
Do you have any idea if this would work, and how?
Can you give me an example of a SysEx string? The incoming patterns must be the exact byte length if the incoming SysEX message. You could then use rules to extract the data and put it in whatever output form you would like.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Yes, the issue with the same length is probably the problem, since I want to see ALL Sysex data and not just specific strings whose length I know in advance.
A few random examples (and these are short ones):
F0 41 10 00 00 64 12 18 00 00 3F 01 28 F7 (something from Roland)
F0 43 20 7F 1C 02 0E 25 00 F7 (request from Yamaha Montage)
F0 F42 30 50 4E 04 F7 (Korg)
…
Except for the F0 at the beginning and the F7 at the end, they’re all formatted slightly differently and, above all, vary in length.
If I want ALL the Sysex bytes to convert them into visible characters, the length doesn’t matter at first. But if Midi Translator doesn’t recognize a Sysex whose length it doesn’t know beforehand, then that won’t work.
That’s why I thought I could just use the “F0” and “F7” bytes as triggers and then simply convert what’s in between. I guess it’s not that simple after all, is it?
Unfortunately, no the entire pattern must be received (including the correct length) before any processing occurs.
This is how the host operationg system processes these messages as well. So you would have to varying length incoming trigger each that match the pattern and length of the incoming SysEX message. Once the message is received, however, you could split pieces of the message out to individual output bytes or use the perform command to execute various outgoing actions based on the bytes received.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Ah, OK, I kind of suspected that. For relatively short Sysex chains, that would still be doable - up to 15–20 bytes - but sometimes they can be hundreds or even tens of thousands of bytes long . OK, anything longer than the length I would have set as a trigger in Translator would then be ignored.
Well, then there’s nothing to be done, I don’t think it’s worth more effort for this little experiment after all.
In any case, thanks a lot for your help, that’ll probably save me hours of fruitless trial and error
Best!
Helfried
Most vendors break up their long SysEX strings into smaller manageable chunks so that devices with less memory can process them. But yes, larger messages could present a problem as well and you would need patterns with every possible lenght if SysEx strings.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
. OK, anything longer than the length I would have set as a trigger in Translator would then be ignored.