I agree there are some errors in the datalist.

It is true this is an error page 187.

Page 194 'Midi Mode' at 00.00.30 have never been documented so it's logic you don't find hybrid mode as well as multi and single mode.
It's an old omission since the introduction of Single Mode on Montage.

I don't see what is unclear page 202 for 'Super Knob LED Pattern' at 30:4B:11 :
Data range is 0-11h so we have 18 discrete values from 0 to 17d.
Description column describe theses 18 values in a comma separate list.
So 0 is 'Type 1' and 17d is 'Off'.
It's said default value is 0, so default value is 'Type 1'.

It's always the same syntax in the datalist, comma separate list for discrete values from min range to max range, '-' for a range, more complex values are more detailled as you can see for 30:42:43 but it's always to read the same way.

eg :
At 30.42.47 'Variation Switch' : Range is 0-1, description is : 'Off, On' so 0 is 'Off', 1 is 'On'. Default value is 1 so default value is 'ON'
Or
At 30.42.45 'Variation Pan' : Range is 01-7F so we have 127 values. Description say :'L63 – C – R63' so 1 is 'L63' and you can calculate 63d is 'L1', 64d is 'C' , 65d is 'R1', and 127d is 'R63'.
default is 40h or 64d so default value is 'C'

But you have an error at 30.40.5B 'swing offset' : It's said Range is 0-1 for first byte and 0-7F for second byte but the true is 0-1 for first byte and 08-78 for second byte
So if we said h is byte at offset 5B and l is byte at offset 5C formula is : display_value = (h * 128 + l) -128
so min is h=0, l= 8 then display_value = (0 * 128 + 8) -128 = -120
max is h=1, l=78 (120d) then display_value = (1 * 128 + 120) -128 = 120
It is said default value is 1(High byte h) 0(Low byte l) so display_value = (1 * 128 + 0) -128 = 0 (and it's true of course)
You can verify all that by dump.

I agree with you that we can easily find the parameters not (or poorly) documented with the right tools.

I have made a post for asking for update datalist because I was hoping to update my program with the Montage datalist, as I did not have a Montage to study the dumps, I had to wait for the update for the Modx.
Which gave me the time to study montage_fr_nf_g0.pdf also when I installed the new OS on the Modx, it took me little time to find all the new parameters because I knew what to look for.

It take more time to find what I need in .X8A file and we can't find via midi dump.
eg : the path and name of audio file when a slot of datalist is 'Audio' type.
This is because X8A/X7A file are not documented.
Even if the basic structure of these files are the same since the Motif as Chris Webb describe in his document we can found at https://gist.github.com/arachsys/2883877
But when we know ELST and DLST are Eentry and DataEntry for LiveSets in the Catalog, we can follow the chunk chain to find what we want.

Everything is not so simple. For example find and understand the table of correspondence between the internal numbers and indexes of libraries with their names.
Because this data structure is different from that described by Chris Bell and not referenced by Catalog.

Now as the title of the post is 'Send SysEx Message to Modx' some Fun:
- On Montage/Modx press 'Live Set' button
- With Midi-Ox or your favorite DAW send these Parameter changes and see what append on the screen of Montage/Modx :
- For Montage send F0.43.10.7F.1C.02.09.00.00.n.F7 with n varies from 0 to 7
- For Modx send F0.43.10.7F.1C.07.09.00.00.n.F7 with n varies from 0 to 7
- Now you know how to change liveSet and you can use Program Change (MSB.LSB.PC) as described page 191 of datalist to select your slot in current LiveSet.
- For programmer, you can now send a request dump at 0E.51.00 (cf page 193) to receive the liveset you have selected by parameter change 09.00.00.n

Here is the protocol to write liveset:
First select your liveset by sending parameter change 09.00.00.n (n=0..7) to transfer the liveset to buffer liveset memory
Then write your liveset in buffer liveset memory as described page 196 via parameter changes.
Then write your liveset from buffer memory to user memory via parameter change 09.00.01.n (n=0..7)
(This like you press 'Store' button to transfer Performance buffer memory to User memory)

Errata:

n varies from 0 to 8 not 0 to 7.

Here is the protocol to write liveset:
First select your liveset by sending parameter change 09.00.00.n (n=1..8) to transfer the liveset to buffer liveset memory (you can't wite liveset 0 = preset)
Then write your liveset in buffer liveset memory as described page 196 via parameter changes.
Then write your liveset from buffer memory to user memory via parameter change 09.00.01.00
(This like you press 'Store' button to transfer Performance buffer memory to User memory)

@Tino:
Hello.

Yes I receive 00.7F.00 , I search what it is

For now, no idea.

For the liveset new parameters:

Page 196 of datalist :
bloc 04 ps 00
and bloc 05 ps 00
have now a TOTAL SIZE of 32(d) not 26(d)

At offset 1A of these blocs you find the type of slot
0='Perf.',1='Song',2='Audio',3='Pattern'
At offset 1C of these blocs you find the index of the song or pattern when typeSlot is 'Song' or 'Pattern'

I don't see what is unclear page 202 for 'Super Knob LED Pattern'

We have a different definition of "clear". To me, inferring that a list is in numerical order from lowest value of a range to highest value of a range is more of a guess than something that has clarity.

It would be more clear to have the values explicitly defined in the list. Yamaha documents many parameters with the values paired with the value's meaning. If you did not have either a Montage nor a MODX to verify - you would be "shooting in the dark" using these under-documented parameters. I do not like counting on luck so everything is approached as if there was no credible documentation when I run into these under-documented parameters. Fully documented parameters are subject to typos - but there is more confidence when I see 00=meaning 1, 01=meaning 2, 02=meaning 3. versus a list that depends on inference.

Super Knob LED is but one example. It's a valid example for that class of documentation weakness.

Please, say me anything about it.
F0 43 20 7F 1C 07 65 00 00 F7 - SysEx from one my friend that I send to MODX.
F0 43 00 7F 1C 00 05 07 65 00 00 01 13 F7 - SysEx received to cubase.
What mean this new command? How I can to use this SysEx?

And my friend chocked by not known received code)))

Break it down ...

F0 43 20 7F 1C 07 65 00 00 F7 - SysEx from one my friend that I send to MODX.

Everything is documented in the data list.

F0 43 20 - that start - matches "BULK DUMP REQUEST"

The "2n" means that "n" is replaced by a device number. The reason why this exists is to enable more than one MODX on the same MIDI bus and address each one individually. If you have only a single MODX per MIDI bus - then this can be "0". Generally, just assume the 3rd byte's "n" is 0 and you're OK. There are corner cases - but unlikely most users have more than one of the same exact keyboard family (family meaning 6 7 or 8 version ... MODX6-8 are all considered to be "the same" for this) on the same MIDI bus. Your message has this as 0. That's fine.

7F 1C 07 are all standard ... OK

Next you have 65 00 00. That's an address. 65 (hex) for high, 0 for mid, and 0 for low. You look elsewhere in the manual to find what that means.

... and you shouldn't find anything.

This makes me wonder what is the intent here. This is 65 hex. Sometimes this is a mistake and 65 decimal is entered as 65 hex. 65 decimal would be 41 hex. Let me find that on the data list.

In the data list this is shown in the bulk dump block charts as "41 ep 00". Where e=element# and p=part#. So "41 00 00" for the address would decode to NORMAL PART ELEMENT (Part 1, Element 1). Because e=0 means element 1 and p=0 means Part 1.

That said - the request is malformed if this is what you want. It should say 41 (since these are all hex values) not "65" (hex). 65 hex is a road to nowhere or something undocumented.

F0 43 00 7F 1C 00 05 07 65 00 00 01 13 F7

This is a bulk dump. I'm not sure entirely which bus this is on (MIDI IN or OUT) so it's either the return data for a dump request from the keyboard or a command from the computer to change (dump) values to the keyboard.

The breakdown is the combination of 2nd and 3rd bytes (43 0n where n again is device # ) represents "BULK DUMP". After the 1C is 00 05 which are "bh" and "bl" meaning high and low bytes of a byte count of the following data. "00 05" means 5 bytes. The "07" is standard stuff. Next "65 00 00" is the address. That 65H (hex) address that's either wrong or undocumented. Then what follows is "01 13". Which is a data byte of "01" and "13" is the checksum.

Elsewhere in the data list is some more information on checksum (check sum):

The Check sum is the value that results in a value of 0 for the lower 7 bits when the Byte Count, Start Address,
Data and Check sum itself are added.

Let me translate that for you:

Take all of these bytes:

Byte count (bh AND bl) - 2 bytes
Start Address (ah am AND al) - 3 bytes
Data (all bytes - how ever many there are) - 1 byte in your example

And add these together. Then subtract from 100h (hex). Then truncate the upper part - just leaving the lower 7 bits.

So for this - we've established bh=00, bl=05, ah=65, am=00, al=00, data bye(s)=01 (just one byte) and we're calculating the checksum cc.

Add those together bh+bl+ah+am+al+dd.. = 00h+05h+65h+00h+00h+01h = 6B

100h-6Bh = 95h. Truncate to lower 7 bits = 15h I don't get 13h like the message shows. Invalid?

What are you trying to do? What's the intent? I would have to look at a good dump to validate I'm applying the data list correctly - I have found errors in the data list that I resolved through looking at what the keyboard responded with.

If this is undocumented stuff the keyboard does behind the scenes - then it will remain undocumented. If it's your own messages - I think there are problems here.

Let me take another swing here - because the docs aren't exactly clear or accurate - so I had to look at real "trusted" data. I'm not going to copy my notes from the trusted data - but will take the result of that double-check and apply it to your data:

F0 43 00 7F 1C 00 05 07 65 00 00 01 13 F7

13H as the checksum is correct but you have to follow a different algorithm than what the documentation states. Worked with "trusted" data and your data alike. Therefore, I have confidence that at least the 13H at the end is a valid checksum.

You don't add the byte count into the checksum. Instead - you add everything (yes, everything - inside the framing bytes) after the byte count. The SysEx framing bytes F0/F7 don't count. They're not part of "everything" here.

And my friend chocked by not known received code)))

The part of my breakdown that most applies most to your over-arching question or concern ("why did it choke?" ) is about the address. And thinking most likely you plugged a decimal number in where it should have been converted to hex. I see this all the time and even Yamaha made this mistake themselves on controller assignments. In the case of Yamaha's mistake - it didn't hurt anything - but it did make the Motif and Montage less "plug and play". If my assumption is correct then your mistake creates an invalid message with no matching address.