I have 2 questions:

1)

At page 193 of the data list we have the Midi Parameter Change Table that lists the various H:M:L addresses. I see that address M = 25 and M = 52 are both listed as "Performance Edit buffer". Why there are two? Isn't the performance edit buffer one and only one? And if it is one, why we have two different addresses?

2)

I see that I can change (almost) all parameters of every single part (the AWM2 or FMX parameters that defines how a voice will sound, the same that can be changed on the MODX display) remotely through sysex messages. This is useful to control the MODX sound generation engine through a PC program.
What I do NOT see is the sysex message to choose if a voice is AWM2 or FMX. I could send sysexes to change an AWM2 element, I could send sysexes to change an FMX operator, but how do I determine if the voice I am shaping through sysexes is (= will play as) AWM2 or FMX?

Regards.

1) They are not documented as the same.

M=25: Performance Edit Buffer (nn = 0)
M=52: Performance Edit Buffer Part nn (nn = 0 – 15)

So M=25 is Performance Common and M=52 is PART (L=n=0 for PART 1, L=n=1 for PART 2, and so on)

2) If you bulk dump a Performance setup as you want it - the PART(s) will assume AWM2, FM-X, or Drum Key according to the bulk dump contents. X8B and MODX Connect is one way of doing this - but you can manually do dumps as well. Setup a Performance with the PART(s) assigned to FM-X/Drum Key/AWM2 and this should "dump back" the starting spot you prefer. I'm not sure if Sysex can dynamically alter after instantiation - but you can try. The different Sysex (in the bulk) for AWM2 vs FM-X vs Drum key in parameters would be H=41,42 vs 48,49 vs 5p. Likewise, the bulk dump blocks have their own dedicated sections for AWM2/FM-X/Drum Key. Easiest would be to dump a block and dump the FM-X block for a particular PART that happens to be AWM2. I take it this would work. There's not a single parameter that "switches". This may have deemed to be an initialization issue better left to block dumps so parameters are properly set.

If you request a bulk dump with 0E.25.00 you will receive the entire buffered performance.
That is the performance common and all active performance parts.

(There is a big difference with Montage OS prior to 2.5. In these old versions you received all 16 parts. Non active parts are initialised with default values.
This is a big difference because a dump of the ROM is about 20 minutes versus 1h30 in Montage OS < 2.5
This is because you have 1588 single performances on a total of 2199 performances (Modx).
On Modx the bulk dump send always only the active parts regardless of OS version.)

As Jason said there is no a single parameter wich indicate a part is AWM, FM, or DRUM

As an example here is how I proceed in my programs :
I received the entire performance in a dictionary structure, an association of keys and values, where the keys maps those you see in page 192 of datalist :
First key is 0E.25.00 (header of buffer performance) then 30.40.00, then 30.41.00 until 0F.25.00 (footer of buffer performance)
and the value is an array of bytes whose values correspond to those found in the datalist for a given key.
For exemple page 197 of datalist for the block 30.40.00
You can read the lenght of block is 94 (decimal), and at offset 94 (5E hexa) you find the checksum of the block.

Then for finding the type of each part :
For each part (p=0 to 15):
I ask the block 31.0p.00 : if there is something (or no error accessing this block ) I read the byte at offset 16 and mark that part active or not.
Else I mark that part not active.
Then for each active part (p) :
I ask the block 41.0p.00 : if there is something (or no error accessing this block ) I mark this part (p) as AWM.
Else I ask the block 48.0p.00 : if there is something (or no error accessing this block ) I mark this part (p) as FM.
Else I mark this part (p) as DRUM.

You can change a part (p) by sending an empty part, with all default values found in datalist, and send then in part performance edit buffer
with a bulk dump where the header is 0E.52.0p as you can see in page 192 of datalist.

Do not confuse changing a parameter of a performance (F0.43.10.7F.1C.07....) and changing a parameter in a bulk dump and sending them (F0.43.00.7F.1C.....)
In the last case you have to recalculate the correct checksum and insert them at the end of the block before sending this block.
How to calculate the checksum is found at page 188 section (3-5-4) BULK DUMP of datalist.

Of course, all that requires a programming language, you can't make that with Midi OX for exemple.
(In my case I use python and a python dictionnary as the data structure)

Don't forget also, datalist of Montage and Modx are not accurate since the last OS version.

(I can give you the paramaters I have found for updating my program for the last OS version, I have made a tool that finds the addresses concerned when we change a parameter)

Jason, Jean thank for your replies. I can follow you perfectly since I am a C++ programmer.

I still have some doubts:

1)

What is the difference between the header/footer pair 0E.25.00 / 0F.25.00, and the seemingly similar 0E.52.nn / 0F.52.nn + 0E.53.00 / 0F.53.00 ?
With the former I receive a large bulk dump containing common + 16 parts, while with the latter I designate (and receive) only a single part or common?

After the first bulk dump write (0E.25.00 / 0F.25.00, to initialize the machine to a known state), is it possible to change incrementally the state by sending single H:M:S parameter change messages (F0.43.10.7F.1C.07....) or (F0.43.10.7F.1C ....)?

2)

Since the whole performance (common + 16 parts) is only a few kilobytes, may I expect a transfer time in the milliseconds range (after all USB2 connections have a practical bandwidth of ~40 MBytes/s)?

If I only sends a few H:M:S messages (maybe a few hundreds bytes at a time), may I expect a nearly instantaneous (<< 1 ms) transfer and feedback from the synth's audio-out?

3)

To change from AWM2/Drum/FMX (in any combination) the only possible way is to send a 0E.52.nn / 0F.52.nn bulk dump with ALL the data (the whole H:M:S collection, except the address/value pair not applicable to the given voice type)?
To state the question differently: does the MODX firmware only change the voice type (AWM2/FMX/drum) if it sees a (valid) 0E.52.nn / 0F.52.nn bulk dump? What happens if I send a single H:M:S parameter change message for an FM operator to an AWM2 voice (or viceversa)? Is it ignored?

4)

Why data lists are not accurate? It seems they have been updated to take into account the last OS update (2.00). File name: modx_en_dl_c0.pdf
Did you find some H:M:S not listed in the data list?

Thanks.

Hi HSL

1) 0E.25.00 is for requesting the entire performance (common + all active parts)
0E.52.nn is for requesting the part nn (0..15), if the part is not active you receive an empty part (default values of datalist)
0E.53.00 is for requesting the common performance
I always use 0E.25.00 (and no 0E.52.nn and 0E.53.00) because as I have said you only receive active parts(for Montage since OS 2.5).
As I dump (the ROM when OS change) all the User and Libraries with my program, the time of dump is important for me (as I said >1h30 with all parts send < 20 mn with all active parts for the Rom).
After the first bulk dump write (0E.25.00) you can change a parameter with F0.43.10.7F.1C... (parameter change) for an active part or common parameter.
For an inactive part you have prior to send a bulk dump with an initialised part (default or coherent values) and so you choose the type of that part (AWM, FM, DRUM)

2) Sending a parameter change is very quick, I have no measure but you can do that while playing a performance with arpeggios, etc.
Sennding a bulk is also very quick also but I never do that while playing. You have to test.
What I know is if I send a whole performance without a pause (a few miliseconds) between blocs, Modx often hangs up.

3) Changing a FM parameter for an AWM part is ignore because the adresses (41XXXX or 48XXXX or 5XXXXX) are not the same except, of course, for the part common (31XXXX to 38XXXX)

4) For Bad Mister, this is only a question of time before the list is accurate.
There is no, as I know, new blocs (HH:MM:LL) with last OS, but inside the blocs there are new parameters (I can send you if you want).
What is not documented in datalist from the first version is how to dump all the Live Sets. You can only dump the current live Set.
(I can explain how dump all the Live Sets if you want)

EDIT - Note, initially my bulk dump read was bad. I've adjusted buffer delays and my software settings to compensate and appear to get better results. Changes below have been made to reflect this. As such, some feedback to the original version of this post may not make sense in the new context. Understand that this picture below was once flawed.

@HSL:

You could, and should issue block dump messages which make no changes to content in order to discover what the content is. Returned from each block dump, along with a header (which is basically a repeat of what you asked for) are many HH:MM:LL parameters that you can look up in the documentation and see for yourself what is returned.

Here's some analysis showing (some of) the difference between 25 and 52 as well as demonstration of portions which overlap in both:

I don't have a MODX so this is Montage. And represents the "CFX + FM EP 2" preset. Chosen because it was the first "simple" Performance with 2 PARTs total.

@Jean:

Lots of things are not documented in the Data List - but a majority of these can be figured out by saving a user file and looking at Performances saved which have the new settings (such as hybrid mode, etc).

----

@HSL:

I understand the wish that one could read documentation and that documentation would be so clear that no investigation be done. However, it's common that there are holes in the docs (missing information) or even incorrect information in the docs. The Montage docs I'm looking at have an error with the Bulk Dump request in the receive flow tree - for example. There's another part of the documentation that does not have this error. Then as firmware is updated - as Jean has alluded to - there are lots of new features one would think would have some features in the data list to document the new values/ranges of existing parameters or new parameters altogether. But these are missing. There is some hand-holding of spelling out what exactly every single part of the data list "means". However, I have not seen anything thus far that couldn't be figured out by inference between the documentation and what the instrument returns when reading. Combined with changing values and seeing how the resulting dumps change as the changes are made.

@HSL:
If you are programmer, I suggest you make a quick program, that request a performance, store it to memory.
Then after changing a parameter on Modx, request a new dump, compare to the first and display the differences in the form bloc_offset= value.
Not only you can quickly discover what adresses ( blocs and then offsets) are affected but you can discover the range of values without having generating a lot of files.
This is the way I have write my tool and update my datalist without scanning files by eye.

I can assure you that you do not miss any of the content of a performance after receiving a dump by sending a dump request to the address 0E.25.00
You receive, of course, bloc 31.00.00 (wich start with part 1 name) and bloc 31.10.00 (wich start with lane 1 switch for part 1) and all other blocs for common and active parts.

The memory structure don't change by the way you initiate your dump request (whole performance, common performance or individual part).
The only difference is an individual part dump request of an inactive part return an initialised part.
And an inactive part is not send when requesting a whole performance.
Which is a very good thing where you dump the entire memory (all the performances).

@ Jason:
I think you have assume of the order of the blocks but the datalist said : "The Block from the Bulk Header to the Bulk Footer of the Performance can be received regardless of their order." or you have a transmission error.

Jean's assumption:

I think you have assume of the order of the blocks but the datalist said : "The Block from the Bulk Header to the Bulk Footer of the Performance can be received regardless of their order." or you have a transmission error.

Documentation does not claim if the blocks come in out of order, there will be a transmission error.

This is the data list documentation:

The Block from the Bulk Header to the Bulk Footer of the Performance can be received regardless of their order.

They can be received even if all of them are not transmitted.

They cannot be received if the irrelevant Block is included.

To execute 1 Performance bulk dump request, designate its corresponding Bulk Header address.

To summarize, I've broken up the documentation into 4 statements with returns between.

The first sentence says that MODX will not see an error if you block dump (FROM your software/utility -> TO MODX) in a different order than how MODX itself dumps out data in the reverse direction (FROM MODX -> TO software/utility). In fact - there is no such thing as order - so there is no concept of "incorrect ordering". The ordering is arbitrary. MODX may happen to always order its dumps a certain way when transmitting. But it doesn't have to in order to comply with this spec. It probably only is consistent because it takes more code to make the dump random than to make it predictable. That said - if your software is not tolerant of arbitrary ordering - then this could come back to bite you as your software implementation is more rigid than the specification allows for.

The second sentence says you can even leave out blocks between the header and footer and MODX will not see this as an issue. You're allowed to send partial data.

The third sentence says it IS considered an error if you send data that is not expected. Like data from a different block. This would be invalid and seen as an error.

The last sentence is simply guidance on how to get MODX to transmit Performance data (a clue as to which header to send for your request).

@ Jason:

I have not said if blocs are not in the order you see in datalist then this is a transmission error.

I would say if you don't find bloc 31.10.00 after a request dump at 0E.25.00 then you have assume there is a order OR you have a transmission error.

You reverse what I'm saying by thinking I assume there is a order (perhaps due to my bad english but I have said "or you have a transmission error" and not "then you have a transmission error")

My program have made hundreds of performances dump reading and writting and I can assure you I always have the bloc 31.10.00 when reading a whole performance by 0E.25.00 or 0E.mm.nn as described page 193 (except the very rare cases I have a transmission error)

I see what you mean. Yes, very likely there's missing data in my dumps since I don't have my keyboard properly settled in the studio. I was using a hack job cable that retracts and may not be up to snuff not to mention going through a USB adapter on my laptop since there is no room for a proper cable I have a 90deg adapter that I've already had to trash one that doesn"t work at all. Thank you Amazon.

I was surprised not to find blocks as I agree the 25 dump should be a superset.

The main point is that you (in the plural) can do this yourself. My keyboard is more often on the road so it's a hassle for me to plug it into the studio proper.

iOS seems to have a horrible selection of free MIDI tools I can send arbitrary commands (SysEx included) and also capture responses or I'd use the tablet for this kind of thing.

Why data lists are not accurate? It seems they have been updated to take into account the last OS update (2.00). File name: modx_en_dl_c0.pdf
Did you find some H:M:S not listed in the data list?

"Why"? Or do you mean "how"? I don't know why the documentation isn't updated in a complete manner. My speculation is that they have to engage the documentation team a long time before the firmware is finished and some details fall off the plate. Speculating even more, I imagine there's some things that are not high on the list of documenting correctly or fixing.

... but for the "how", some issues:

modx_en_dl_c0.pdf page 187

-
F0H 43H 2nH 7FH 1CH 07H ahH amH alH ddH...ddH F7H

ddH..ddH doesn't apply to a request. The bulk dump request is more properly documented on page 188:

(3-5-5) DUMP REQUEST
11110000 F0 Exclusive Status
01000011 43 YAMAHA ID
0010nnnn 2n Device Number
01111111 7F Group ID High
00011100 1C Group ID Low
00000010 07 Model ID
0aaaaaaa aaaaaaa Address High
0aaaaaaa aaaaaaa Address Mid
0aaaaaaa aaaaaaa Address Low
11110111 F7 End of Exclusive

Notice between the addresses (high, mid low) and End of Exclusive (F7) - there's no data. That's correct.

The focus of this primer (1st message) is on parameters since this is generally what folks are tinkering with and I like to have a primer to throw at those users.

Another issue on page 194 - not updated for new OS. Address 00/00/30 shows MIDI modes 00=Multi, 01=Single. I'm guessing 02=Hybrid - but Hybrid isn't documented here.

Another type of issue that comes up is the document may not tell you 00=one option and 01=another and 02=some other. It may not be spelled out. Take page 202 Super Knob LED Pattern (30/4B/11). We know the range is between 0 and 11 hex (that's 17 decimal). It does not tell you what value matches up with what type and which value matches "OFF". We can just make some assumptions here. Since when you initialize MODX superknob is flashing (NOT off) - you can assume that "00" - which is the default is also not "OFF". So maybe the types are just in order. 0=Type 1, 1=Type 2-1, ... and so on in order until 0x11 (11 hex) = off. Maybe this is wrong. You can certainly figure out which number is off on your own. This isn't the only parameter that's similarly under-documented.

These sort of broken or missing items aren't necessarily deal breakers. Most of the time you do not need any help to poke at MODX then peek at the answer.

Hi Jean,

What is not documented in datalist from the first version is how to dump all the Live Sets. You can only dump the current live Set.
(I can explain how dump all the Live Sets if you want)

I am interested for how you can get all Livesets data. Can you give more details ?

By the way, on my Montage 3.00.1, I receive an undocumented message when requesting a performance block dump, just after the bulk dump header:
F0 43 00 7F 1C 00 08 02 00 7F 00 01 00 00 00 7E F7
Adress 00 7F 00 is unknown. The message is always the same from any performance. Do you know what it means?