Notifications
Clear all
Topic starter
Perfs that use morphing always have a part 1 and have one or more parts in the 9-16 range that are actually used for the morphing with the result winding up in part 1.
They may also have other 'normal' parts in slots 2-8 but many morph perfs don't use those slots.
The 'Morph The EP MW' perf uses parts 1 in the 1-8 range and parts 9,10,11,12,13,14 in the 9-16 range.
When you bulk export that perf the dump includes SysEx records for parts 2,3,4,5,6,7,8 even though those parts
are NOT actually part of, nor used by, the performance.
This is a summary showing the part names in the dump
203,Morph The EP MW,0,Morph The EP MW,8
203,Morph The EP MW,1,Initialized Part,8
203,Morph The EP MW,2,Initialized Part,8
203,Morph The EP MW,3,Initialized Part,8
203,Morph The EP MW,4,Initialized Part,8
203,Morph The EP MW,5,Initialized Part,8
203,Morph The EP MW,6,Initialized Part,8
203,Morph The EP MW,7,Initialized Part,8
203,Morph The EP MW,8,KEYBOARD,8
203,Morph The EP MW,9,KEYBOARD,8
203,Morph The EP MW,10,KEYBOARD,8
203,Morph The EP MW,11,KEYBOARD,8
203,Morph The EP MW,12,KEYBOARD,8
203,Morph The EP MW,13,SYN LEAD,8
There are 97 records in the dump for each of the unused part.
The issue is that there doesn't appear to be ANY indicator in a dump file that tells you how many parts a performance actually uses.
A dump of non-morph perfs does NOT include data for unused parts so if there are dump records for a part you know that part
is actually used by the performance.
The inclusion of unused part data is likely just a side effort specific to morph performances. I don't know why it would be
necessary, or beneficial to have this data in the dump. Morph dumps are already much larger because they have a 3k record
for the morpth data and another 3k record for the PNG graphic data.
Having unused data in the dump wouldn't be a problem if there was some way to distinguish between used and unused data.
This makes it problematic to display the structure of a performance since the unused part data can easily be mistaken for used
data in trying to determine what the performance does.
Posted : 04/11/2023 1:50 am
Is there a difference between adr1/adr2/adr3/adr4 as 0x10/0x00/0x01/0x00 and 0x11/0x00/0x01/0x00? If so, what are these values?
... In the bulk dump of this Performance.
0x11/0x00/0x01/0x00
0x12/0x00/0x01/0x00
0x13/0x00/0x01/0x00
... Through
0x17/0x00/0x01/0x00
Should all be the same.
Listing only adr1 now: And then 0x18 ... 0x1D should match the first Part (starting with 0x10)
Posted : 04/11/2023 3:41 am
Topic starter
Is there a difference between adr1/adr2/adr3/adr4 as 0x10/0x00/0x01/0x00 and 0x11/0x00/0x01/0x00? If so, what are these values?
Not sure just what you are asking. Page 211 of the Data doc is the 'Performance Part' table and it lists the possible values for all 4 addresses for each part.
These are the addresses in the dump for part 1 (0 based). There is the same full set of records for parts 2-8.
0D 10 00 00 00 Part Name
0D 10 00 01 00 Part 1byte - all parms in the table matching these address are only 1 byte of data table
. . .
0D 10 00 09 00 Key Controller Box
0D 10 03 00 00 Scene Part - there are 8 of these records - one for each scene
0D 10 03 01 00
. . .
0D 10 03 07 00
0D 10 04 00 00 Assignable Knob Name - 8 of these records
0D 10 04 01 00
. . .
0D 10 04 07 00
0D 10 05 00 00 Controller - 32 of these records - one for each controller
0D 10 05 01 00
. . .
0D 10 05 1F 00
0D 10 06 00 00 Motion Seq Part/Lane Settings 1byte - 4 records - one for each possible lane
0D 10 06 10 00
0D 10 06 20 00
0D 10 06 30 00
0D 10 07 00 00 Motion Seq Part/Lane Settings 2byte - 4 records - all parms in this table are 2 long
0D 10 07 10 00
0D 10 07 20 00
0D 10 07 30 00
0D 10 08 00 00 Motion Seq Lane Sequence - 32 of these - 4 lanes * 8 sequences
0D 10 08 01 00
0D 10 08 02 00
. . .
0D 10 08 37 00 - note each group of 8 has address3 from 0-7 - that is why this one is '37': 30, 31...
The unused parts have the same records. The first post data is: perf No., perf Name, part No., Part Name, Element Count.
I can post the full dump file if you give me a link to post it to. It is a plain text file
1.86 MB (1,953,792 bytes). These are the first 3 records:
F0 43 00 7F 1C 00 05 0D 04 00 01 4A 24 F7
F0 43 00 7F 1C 00 0B 0D 00 00 7F 00 00 01 00 00 00 00 73 F7
F0 43 00 7F 1C 00 19 0D 06 00 00 00 4D 6F 72 70 68 20 54 68 65 20 45 50 20 4D 57 20 20 20 20 20 0D F7
Those last 4 values were wrapped - they belong at the end of the 3rd line.
The first line is the Bulk Header - the '01 4A' is the performance number - 01 -> 128 + 74 = 202
zero based so performance number is 203. The 01 high order byte has to be shifted right one position - it represents bits because the low order bit is really bit 8 of the first byte.
The second line is the SoundMondo version record that I ask about in a previous thread.
The third line is the performance name record - I'm sure you can recognize the ASCII codes
for 'Morph The EP MW'
All possible part records are present for all parts 1-8 but for parts 9-16 only records (a full set) for
used parts are in the dump. Unused parts in the 9-16 range are NOT in the dump.
So the question becomes - how do you tell if a part from 2-8 is actually used or is just a fluke
dump that is part of the unused parts?
I can't find any parameter that might indicate that. Never heard of a 'Part ON/OFF' switch'.
Posted : 04/11/2023 4:21 am
(Minimally) I'm asking in your dump of this performance what the data return is for those addresses.
0x10/0x00/0x01/0x00 and 0x11/0x00/0x01/0x00
Which you would notate (in hex) as
10 00 01 00
and
11 00 01 00
each of these addresses I asked for would have a 1 byte data value. I'm wondering what those are.
0D 10 00 XX addresses you listed are not what I was looking for (I saw you listed one with the right address but no data value).
0D 10 00 01 00 Part 1byte - all parms in the table matching these address are only 1 byte of data table
Right address (the 0D in front is extraneous - not part of the address. adr1=10, adr2=00, adr3=01, adr4=00) but no data listed. And then the other addresses requested weren't investigated.
I understand what you're saying about the "extraneous" data - but I doubt there's a problem here for parsing as I think there are breadcrumbs that tell software (and the keyboard) to ignore this data. Hypothesis is that the addresses I asked for is where this is stored.
Posted : 04/11/2023 7:11 am
Topic starter
I'm asking in your dump of this performance what the data return is for those addresses.
Perfect - that 1st byte is the Part Switch - somehow I hadn't noticed that before. That answers the
main question of how to tell if a part is being used. That is what I needed to help filter 'unused' data
out of the dump.
I modified my test code to add a few more parms to a flattened text file. It produces a set of data
for all 3369 performances. This is the result for the 'Morph The EP MW' performance.
I'm finding these files really useful for figuring out what performances use a particular feature.
The parms I am selecting are just perf and part level and just to help me figure out the best way to
dump data so people can load it into Excel easily.
Maybe multiple files since the data needs to be flattened and that means nested data repeats the data at the higher level. So higher level data would be limited to just perf No and Perf Name, Part No. and Part Name to avoid duplicate. Then the files could be, conceptually linked by perf No.
So maybe one file with performance only data and parms, one with like the sample below with only part level (no element detail) and perf no. and perf name. And then
one for each part type (element, operator, drum, an-x) with detail parms appropriate for those part types.
I'll need suggestions of what parm info is most useful in finding performances that have functionality
people are looking for. They can then load that performance to do a thorough exam.
Here is the initial sample. You should be able to import this into Excel.
Perf No.,Perf Name,VCM,PartNo,Part Name,Part SW,Part Mode,Part KeyCtrl,Element Cnt
203,"Morph The EP MW",0,0,"Morph The EP MW",1,0,1,8
203,"Morph The EP MW",0,1,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,2,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,3,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,4,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,5,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,6,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,7,"Initialized Part",0,0,0,8
203,"Morph The EP MW",0,8,"KEYBOARD",1,0,0,8
203,"Morph The EP MW",0,9,"KEYBOARD",1,0,0,8
203,"Morph The EP MW",0,10,"KEYBOARD",1,0,0,8
203,"Morph The EP MW",0,11,"KEYBOARD",1,0,0,8
203,"Morph The EP MW",0,12,"KEYBOARD",1,0,0,8
203,"Morph The EP MW",0,13,"SYN LEAD",1,0,0,8
The zip of the above perf is 112 KB and I can post it if someone tells me where. The one 'caveat' with the morph dumps is that the records for the morph data and the morph PNG data are broken into
multiple records when the data is exported since 3k exceeds the MIDI max.
Standalone records begin with 'F0' and end with 'F7' but the 'continuation' records begin with 'F0'. That
'F0' needs to be removed and the entire record added to the end of the previous record. The result should be one LONG record that begins with 'F0' and ends with 'F7' that then FULLY represents
one table entry from the Data List doc.
If anyone is interested I can post a 19 MB zip file that contains dump files for all 3369 performances if someone gives me a place to dump it to.
Once some of the parm data files are available I can dump those too.
Posted : 04/11/2023 3:46 pm
