Dynamic composition of a SysEx message with variable content and length

Scripting with Gig Performer
1

I am scripting some basic display functions to display information on the LCD of my new Icon Platform M+ control surface. I am therefore supposed to compose a SysEx message of variable content and variable length. I have to send a MCP SysEx message like this:

SysExMsg = # F0 00 00 66 14 12 xx cc cc cc ... F7 ,

where xx is the position in the LCD display coded in hexa and cc are ASCII characters also coded in hexa.

Is the only way to compose a SysEx message with a variable content to play with:

SM_ChangeValue(<sm : SysexManager>, <index : integer>, <newValue : integer>) ?

This doesn’t solve the question of the variable size :thinking:

Is there perhaps a way to convert a string into a SysexMessage ?

2

No but I could trivially add these for next update — what exactly do you think is needed? (I don’t use sysex myself ever so some expert feedback is welcomed)

3

I think we have almost everything we need for manipulating a string, so it is not necessary to add something for manipulating a SysexManager. I would propose something like:

StringToSysexMessage(<str String>) Returns SysexMessage;

And by the way, I also need a function like:

Function StringToASCII(str : String) Returns String

I made a script that does it, but it is not the most elegant and efficient one :grimacing:

4

What is StringToASCII supposed to do?

5

Playing with SysexMessage I encountered a strange “syntax error”. If replace the 9 by another digit ranging from 1 to 7 it compiles. I don’t think SysEx have restrictions like using HEX smaller than 7F or something like that… I really need to test with 90.

SysexMessage_syntax_error
SysexMessage_syntax_error.jpg763Ă—432 71.4 KB

6

“Hello World!” => “48656C6C6F20576F726C6421”

7

That would not be StringToASCII, that is StringToHexString — VERY different

8

StringToHexString is perfect for me if the HEX is the ASCII code of the letters. :+1:

9

That syntax error is correct — you cannot have a value with the top bit set, it would be interpreted as the start of a new status message and would immediately abort the sysex processing. So the highest value inside a sysex message can only be 7F

10

I am not a SysEx expert, but the only way to display the extended ASCII set of characters to my control surface LCD is to send values up to FF. This is something I can do with SM_ChangeValue. This way I can put higher value than 7F. I would probably have difficulties to display the character 7F :grimacing:

Where did you see that a SysEx is restricted to values <7F ?

EDIT: 7F is DEL

11

The point is “ASCII” by itself doesn’t determine the number base. I assume what you’re trying to do is generate sysex representation of text, right? If so, then who should make sure that there is never a character in the string that would translate to a decimal ASCII value greater than 127?

12

You are right, I always use HEX for ASCII, but it is me.

No problem, I display it even if is greater than 127.

13

Yes, but if you’re creating a sysex message, you cannot have values > 127 in it

14

Isn’t ASCII a 7-bit code anyway?

15

I have to if I want to display ASCII character with value above 127. I did it and it works. But I have to use SM_ChangeValue to set values higher than 127, because of the current SysexMessage initialization restriction within GP script.

16

Can you explain please? As I said, sysex messages, at least legal ones, cannot have values greater than 127. That is why I put in that restriction. The SM_ChangeValue function shouldn’t allow higher values either. If it does, that’s a bug.

Do you have a synth that is accepting sysex messages with values greater than 127? If so, which one?

If I am to relax that restriction, I need a real example where it is being allowed.

17

Legal ones or legacy ones? I don’t know. It is the first time that I compose Sysex by hand, but I confirm that higher values than 7F are ne eded !!!

Then it is a bug, but shouldn’t consider as a bug. It is perfect like it is. Please don’t « fix it » !

Not a synth, Ă  control surface who follow several standard protocols (MCP/MCU Mackie Control, Logic, HUI Pro Tools) where SysEx with higher value than 7F are needed.
I now own an Icon Platform M+, and the only way to display the whole ASCII character sets if to compose SysEx with value up to FF. And I confirm I sent SysEx with values higher then 7F to my device using SM_ChangeValue to properly display all characters above 7F.

So I really think you definitely shouldn’t restrict the SysEx values to values smaller than 7F. At a time it was probably the SysEx standard but it is obviously no more the case.

18

It is still the standard. Do you have a link to a PDF or manual describing this for that device?

19

That’s really strange. I can confirm that SM_ChangeValue() allows for newValue to be greater than 127. But in my experiments, the resulting behavior seemed to be that the value of the byte is actually set to newValue % 128.

The script below sends MIDI messages, when a button is pressed, alternating between a payload byte having the (decimal) values of 1 and 129. I could not differentiate this messages using the GP MIDI Monitor or an external MIDI monitor tool (Pocket MIDI) when sent over a loopback device:
grafik
SysexMsbTest.gig (7.0 KB)

@David-san can you confirm that your control surface behaves differently when you add an offset of 128 to your values in GP Script?

20

I just took a look at the code for the SM_ChangeValue function and in fact it is doing mod 128 arithmetic (or ANDing with 0x7F if you prefer).

In other words, if you try to change the byte to 0x90, what is actually getting sent out is 0x10. You were never actually sending 0x90 out

Can you check the manual to see if in fact what that device is doing is using LOW bytes to represent those extended characters?

Here is an example where I created your sysex message and then used SM_ChangeMessage to set the 6th byte to 0x90 and as you can see from the Midi Monitor, what was received was 0x10

screenshot_429
screenshot_429797Ă—137 28.3 KB