Open probonopd opened 12 months ago
I think you didn't understand me... The converter does make use of a subset of AMEM, that what MiniDexed implements at the moment. The files from YamahaBlackBoxes site do NOT contain the AMEM section, and that was the problem. The files from that site are not DX7II dumps, but pure DX7 dumps.
DX7 Voice (VMEM) bulk dump = 4104 bytes DX7II Voice + Supplement (VMEM+AMEM) bulk dump = 4104 + 1135 = 5239 bytes DX7II Performance (PMEM) bulk dump = 1650 bytes
Files bigger than the sizes above are probably a combination of multiple dumps in one file.
The converter can convert (to performance.ini):
The converter can also convert (implemented today, but it does not make much sense because we only get dual/split and detune parameters, but nothing about modulations from controllers):
TX7/DX5 PMEM and DX7II PMEM are totally different stories. TX7 PMEM contains a lot of parameters from the DX7II AMEM
Now I understand, thanks for the clarification. So we need to find DX7II dumps that include AMEM.
I found some in BlackWinny collection (Bo Tomlyn, Michael Boddicker, Ten No Maki, Chi No Maki), but not the Yamaha originals
https://github.com/asb2m10/dexed/issues/165#issuecomment-1436586010 talks about the AMEM, is it contained in the zip there?
Looks good:
DX7II Voice Bank Supplement - AMEM at position 16178
Calculated data size: 1120
Real data size: 1120
Checksum match
DX7/DX9 Voice Bank - VMEM at position 17306
Calculated data size: 4096
Real data size: 4096
Checksum match
The converter does make use of a subset of AMEM, that what MiniDexed implements at the moment.
It would be good if it would convert all AMEM parameters, just invent some names for the keys and put #TODO:
in front.
This will increase the chances that MiniDexed will support more eventually.
It is a huge task. I can't do it in one evening, but I'll go for it in the near future. My biggest problem is the non-standard format of INI files that MiniDexed is using. Standard INI files have sections, and one can easily put a new entry in a section. The newly added line goes at the end of the section, but not at the end of the file. So, having sections [TG1], [TG2],...,[Effects] would make everything easier. With INI format used by MiniDexed, one must create the file in one go, no later additions to the file are easy to do.
Explained other way around - MiniDexed INI-files are not suitable to write an unknown number of parameters. You need to know all the parameters you'll need before you create an empty INI file.
So, having sections [TG1], [TG2],...,[Effects] would make everything easier.
I agree... maybe we should implement that first?
From #3
Let's also convert AMEM and put its keys and values into the converted performance; that way, the MiniDexed developers have a target to work against :-)