YamahaSynth.com Forums

This is the place to talk about all things related to Yamaha Synthesizers!
  1. Jason
  2. Sherlock Holmes The Voice
  3. MODX Series Synthesizers
  4. Thursday, 07 November 2019
BEFORE YOU BEGIN (be sure to have):

1) A program on your computer capable of sending SysEx for you. There are several choices - including programming your own webpage with a MIDI interface or a C/C++ program. However, the suggestion is to use a program that is already "off the shelf" with no programming needed.

1.a) Suggestion for x86/Windows PC: MIDI-OX
http://www.midiox.com/mfaq.htm#whyNoSysEx
(above for setup)
Then, within MIDI-OX, click on "View->SysEx". From the Command Window, you can type in SySex data using hex (F0 ## ## ## ## ## ... F7) where "##" is your hex data and each SysEx command begins with "F0" and ends with "F7". Then, use the menu command "Command Window->Send Sysex" to send your SysEx command(s) typed in.

1.b) Suggestion for MAC: Use Snoize MIDI Monitor
https://www.snoize.com/MIDIMonitor/
or
http://www.snoize.com/SysExLibrarian/

SysExLibrarian I believe you have to create a SYX file with your hex data and "feed" it into the utility. I do not have a Mac to provide very detailed information.

2) Your MODX connected to a PC using a USB 2.0 cable between "USB To Host" on MODX and a standard USB connector (type A) on your PC/Mac.

3) MODX should be in USB MIDI mode. On the top line of your display, if the keyboard is in MIDI-DIN mode, there will be a circle with dots in the middle. If in USB mode, you will see the symbol for the USB port which looks sort of like a pitch fork.

4) Be sure to reference the Data List which matches your firmware. The Data List contains all of the published SysEx commands and information on how to construct a valid message.

CREATING A SYSEX MESSAGE:

Preface: The latest firmware version is v2.0 and the associated Data List is "modx_en_dl_c0.pdf". Page number references to the Data List will be using that document. Pages 186-220 cover the information you need to construct SysEx messages. Page 186-188 covers how to construct the general message and pages 190-220 cover all the parameters and what to "fill in" to the general message to change different parameters.

1) Assuming you want to change a single parameter listed on a table between page 190-220, we will need to send MODX something called a "Parameter Change" System Exclusive Message. When we send this message from a computer, MODX will be RECEIVING this message. Therefore, on Page 187 of the Data List - look at "(2) Receive Flow". This summarizes, at a high level, all the various MIDI messages MODX can receive. We are interested in SysEx (System Exclusive). The very bottom of this "tree" we see "SYSTEM EXCLUSIVE MESSAGE" and "<PARAMETER CHANGE>". This line with "<PARAMETER CHANGE>" is the one of interest as we want to change a single parameter. Incidentally, if you want to request MODX to respond with the current setting of a parameter (instead of changing the parameter), you would use the "<PARAMETER REQUEST>" message.

1.a) The "<PARAMETER CHANGE>" format shows: "F0H 43H 1nH 7FH 1CH 07H ahH amH alH ddH ... ddH F7H"

That's the general format of any parameter change. Breaking that down:

The format is showing hex numbers separated by spaces. The capital "H" after two characters is denoting hex. "F0H" would be entered into MIDI-OX as "F0" since MIDI-OX assumes hex and does not need the "H" to tell it to use hex. All hex numbers in the list with ALL CAPITAL LETTERS should be entered in verbatim. If the hex digit has lowercase letters (like 1nH has a lowercase "n", or "ahH" has lowercase "ah" ) then this means we will fill in something here replacing the lowercase letter(s) with hex. These are not verbatim, but "variable" values that can change for every message. Breaking these down:

If we look at the data list page 188, section (3-5-3-1 "NATIVE PARAMETER CHANGE, MODE CHANGE" ) here we see the documentation for each piece of the "<PARAMETER CHANGE>"

1nH (first variable value): Device number. In your [UTILITY] settings, you are able to set MODX to a specific device number. The purpose for this is to deal with MIDI messages when you have more than one MODX connected on the same MIDI bus. By default, MODX is set to respond to any device number. If you have changed your MODX device number (which most people should not have) then "n" should be replaced with your MODX's device number. For everyone else, use "0". I will assume that "0" is appropriate for this tutorial - but be sure to adjust if you're in the minority where you have modified your MODX to respond to a specific device number.

ahH (2nd variable value): Each parameter in the MIDI Data List has a MIDI address. There are 3 parts to the address (3 hex numbers). "Address High", "Address Medium" (or "Address Middle" ), and "Address Low". This variable value is "Address High". We can look at a random parameter to get a feel for how to fill in the right value for "ahH" (address high hex). Look at page 194, the last parameter "Sustain Pedal Select". In this table, the 1st 3 columns are Address High=1st column, Address Medium/Middle=2nd column, Address Low=3rd column. For "Sustain Pedal Select", we see the 3rd column has "3B". The 1st two columns are blank. "3B" is Address Low - we need to look back in the table to find what the Address High should be. Scrolling up, we see the first (non-header) row in this table shows the first two columns as "00 00". Therefore, all the data below has the same Address High=00 and Address Medium/Middle=00. Therefore, we would use "00" for the "ahH" value (Address High).

amH (3rd variable value): See above. Address Medium/Middle. For our "Sustain Pedal Select" example, the 2nd column in the table - the value should be 00.

alH (4th variable value): See above. Address Low. For our "Sustain Pedal Select" example, the 3rd column in the table - the value should be 3B

ddH (5th through ?? variable data value or values): This is the (or are the) data value(s). Each parameter can have one or more data value. The number of data values you have in your SysEx command should match the specification for the parameter you are changing. Most have only one data value - but some have more than one value. Back to our example "Sustain Pedal Select" on page 194. The 4th column of this table is labeled as "Size". "Size" tells you how many data values this parameter is expecting. Here, we see the "Size" is "1" - so there will only be one data value. The 5th column of the table shows us what the valid range of values are. Here, we see the valid range is between 00 and 02. The 7th column tells us what those values mean. Here, I believe the documentation is weak. I would like to see explicit information such as "00=FC3A (Half On), 01=FC3A (Half Off), 02=FC4A/FC5". Instead, we are left guessing. My assumption for these tables is that when there is a list, the list is in order from lowest value in valid range to highest value. Therefore, I assume for this:

00 (lowest value in range) = FC3A (Half On)
01 = FC3A (Half Off)
02 (highest value in range) = FC4A/FC5

The 8th column in the table tells you what the default value is when MODX is initialized. The default for this example is "00" or "FC3A (Half On)"

2) Now use this information to construct a SysEx message. We will change the sustain pedal type from the default value of 00 to something else. Since MIDI-OX and most software does not need the "H" to indicate hex, we will strip that off. Here is the generic message for the sustain pedal:

F0 43 10 7F 1C 07 00 00 3B <dd> F7

Where <dd> is a number from 00 to 02 depending on the sustain pedal selected.

The 3rd byte ("10" ) assumes you have not changed MODX's MIDI device number which is only useful in a scenario where you have multiple MODXs. Modify this to "11" if your device is #1 or "12" if device 2, and so on.

After the "7F 1C 07" are 3 address bytes. 00,00,3B. This is the high/mid/low address we discussed.

Then comes the <dd>. If we wanted to change the pedal type to FC4A/FC5, then the would be 02.

All other values (F0 43 ... 7F 1C 07 ... F7) are verbatim values and will be the same for every parameter change message.

Therefore, the full SysEx command to change the sustain pedal to FC4A/FC5 would be:

F0 43 10 7F 1C 07 00 00 3B 02 F7

ANOTHER EXAMPLE:

Data List Page 197, left-hand side about mid-way down is "Performance Pan" - this is a Performance Common level parameter.

The generic message:

F0 43 10 7F 1C 07 30 40 1F <dd> F7

Where <dd> of 40, which is the default, is center. Value of 01 is pan hard left and value of 7F is pan hard right. So if we wanted to pan somewhere in the middle between hard left and center:

F0 43 10 7F 1C 07 30 40 1F 20 F7

Where the <dd> is 20 (hex) which is half-way between hex 01 and hex 40.

The address low/mid/high is 30/40/1F. Use the same method as the Sustain Pedal example to find what the address high and address medium/middle values should be.
Responses (19)
Accepted Answer Pending Moderation
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. more than a month ago
  2. MODX Series Synthesizers
  3. # 1
Accepted Answer Pending Moderation
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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 2
Accepted Answer Pending Moderation
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)
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 3
Accepted Answer Pending Moderation
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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 4
Accepted Answer Pending Moderation
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)
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 5
Accepted Answer Pending Moderation
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:

https://i.ibb.co/vHrzZTQ/Bulk-Dump-Compares-Montage-Fixed.png

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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 6
Accepted Answer Pending Moderation
@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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 7
Accepted Answer Pending Moderation
@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).
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 8
Accepted Answer Pending Moderation
@ 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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 9
Accepted Answer Pending Moderation
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).
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 10
Accepted Answer Pending Moderation
@ 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)
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 11
Accepted Answer Pending Moderation
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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 12
Accepted Answer Pending Moderation
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
-<BULK DUMP REQUEST>
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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 13
Accepted Answer Pending Moderation
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?
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 14
Accepted Answer Pending Moderation
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)
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 15
Accepted Answer Pending Moderation
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)
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 16
Accepted Answer Pending Moderation
@Tino:
Hello.

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

For now, no idea.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 17
Accepted Answer Pending Moderation
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'
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 18
Accepted Answer Pending Moderation
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.
  1. more than a month ago
  2. MODX Series Synthesizers
  3. # 19
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
2021 © Yamaha Corporation of America and Yamaha Corporation. All rights reserved.