No, you are right, it sends a modulo 128. 126 and 254 is the same arrow character. That’s why I thought I access the full ASCII table.
That’s perhaps why it didn’t work. I had a loot at this manual at page 110:
I am supposed to send:
SysExMsg = # F0 00 00 66 14 90 01 7F
where 01 is the ID of the differents LEDS
The documentation is generic for Logic, not for the Icon Platform M+
I just had an answer from the Icon support. In order to light up a LED I am supposed to send : 09 90 5E 7F (where 5E is the “play” button LED).
Those are not sysex messages — those are just NoteOn messages
So, I misunderstood the manual that I read to quickly. I though I have to add this after a SysEx header. I just tested with:
For i=0; i<=127 ; i=i+1 Do
SendNowExternal(ExtDisplay, MakeMidiMessage(144, i, 127))
End
And I got a Christmas tree, yoo-hoo, every LEDs are lighting 
It is quite close that what the Icon support answered, but they added this 0x09 as a first byte… they perhaps did a mistake 
Many thanks.
Now I am wondering why the GP MIDI sync option doesn’t work for the LEDs. I simply send the same note on message to the control surface that is used to switch on the GP button widget. This is exactly what GP is supposed to do, isn’t it ?
Probably a typo and it was supposed to be 0x90
This makes the button LED work properly:
On WidgetValueChanged(newValue : double) from SEL_BUTTON_1
SendNowExternal(ControlSurfaceOut, MakeMidiMessage(144, 24, Round(newValue)));
End
But, I cannot benefit from the RIG manager as the MIDI note (here 24) is hard coded in the callback.
They wrote 0x09 0x90 0xnn 0x7F 
Ok so that first 0x09 should just be ignored.
So what about the other sysex stuff? Can you confirm that there shouldn’t be values > 127 inside?
SUMMARY OF THE TOPIC
I still need:
StringToSysexMessage(<str String>) Returns SysexMessage;
to benefit from the string manipulation of GP to create Sysexmessage.
A function to facilitate the coding of strings in a SysEx would also be much appreciated:
Function StringToHexString(str : String) Returns String
Regarding the SysEx values I cannot tell anymore that values >127 are needed.
Regarding the LED of my control surface, as I wrote before, this makes a LED switch ON/OFF properly:
On WidgetValueChanged(newValue : double) from SEL_BUTTON_1
SendNowExternal(ControlSurfaceOut, MakeMidiMessage(144, 24, Round(newValue)));
End
But I still wonder why it dosen’t work using GP MIDI sync, because what I send back to the control surface, is the exact same information that is received to switch the widget button ON. This is what GP MIDI sync is also supposed to do, but GP MIDI sync doesn’t work for me. And of course, with my method the note is hard coded and I cannot benefit form the RIG manager regarding the LED activation.
For technical reasons, I can’t create that function right now but I can do this:
var manager : SysexManager
SM_CreateSysexFromString(manager, “#F0 00 00 56 14 12 00 00 7F F7”)
So you could play with strings all you like and ultimately create a Sysex that way
This would be perfect 
This is a bug — I’ve just been able to reproduce it. I’ve put it in our tracking system
Thank you for having for this bug. I think I have found another one regarding the MIDI sync of motorized fader, when activating a new variation.
- I have a set of slider widgets synced to the slider of my control surface
- I create a second variation which holds different values of the widget
- when switching from one variation to the other the widgets values are recalled perfectly but only the last created slider of the control surface moves to the right value
additionnal hints:
- my hardware sliders respond to CC messages…
- when moving manually they keep synced they are only not recalled properly according to the widget values…
Can you please post a screenshot of the midi messages that GP receives when you move those motorized sliders?
I will do it tomorrow, I am out for a gig.
It is a normal CC message with a standard value, if I remember welll, like:
CC 111 nnn
I just moved the first three sliders., here you have:
- When moving the sliders manually, everything is OK.
- When recalling a variation, only the last created slider is recalled and not the others.
- If I remove the sync option to the last created slider, it is the one before which is recalled properlly when switching variations.
- When switching repeatedly from one variation to the other, sometimes, one among the other slider is randomly set to a random wrong value (0 or 127).
Additionnal clue:
I removed the sync option of a slider and replaced it by the following callback function:
On WidgetValueChanged(newValue : double) from FADER_1
SendNowExternal(ControlSurfaceOut, MakeMidiMessage(176, 111, Round(newValue*127)));
End
It behaves the same than with the GP MIDI sync. Manually the synchronization works perfectly, but when recalling from a variation the motorized slider is not synced even if the callback is called with the right value (I printed it out in the script logger). It seems that when the slider callback is called from variation recall, the SendNowExternal function doesn’t works properly.
Is it possible that GP is sending the MIDI events too fast and your device can’t handle/buffer them?
The thing is, if you use something like an X-touch Mini or a MIDI Twister, neither of which have mechanical sliders, but just LED rings around the knobs, they update perfectly when you switch from one variation to another. In fact I made a video of this the other day.