Welcome to SXG-Create-NF Discussions!

[NightFright2k19]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we build together 💪.

[zaphod77]

I'm a person who likes to playback gs and xg midi files. :) i've found many bugs in xg playback.

okay let's summarize the state of things. I'll try now.

1. mu 90 and later roms that use SWP30 include more parameter data in their instruments than 80 and 50. s-mu2000 has a now highly accurate swp30 implementation, so it knows what those parameters are. We need to figure out what parameters can translate, and what parameters we can put into the s-yxg50 engine.

2. the s-yxg50 engine is not accurate, but it's pretty close. there are some bugs that were not present in earlier non VSTi versions, but those version have higher latency. I do not know what they are. some of them i think are solvable with sample replacement, but not all of them.

3. limits need to be raised to handle anything not the orignal mu50 rom, but using the mu50 rom is slightly innacurate, especailyl with starship sample. Fortuantely, it's been fairly simple to raise most of those limits.

4. mu2000, and only the 2000 and it's variants have 3 and 4 element voices. this makes mu1000 conversion incomplete. m yonly idea is baking elements together somehow, and i'm not sure that's even feasable. but if there is code that iterates over the elements, it might be possible to patch that, and turn a 2 into a 3 or a 4.

[NightFright2k19]

The upcoming patch will strongly focus on GS and XG improvements, so let's see where we end up after the release. :) But it's great to have this as a reference point for later.

[zaphod77]

the only way i can think of to improve GS is to yoink roland samples instead and put THEM in. :) say the ones from an SC88?

[NightFright2k19]

That's not my intention. This is supposed to be as close to the Yamaha synth as possible. Importing non-Yamaha samples isn't going to happen with me, I'm afraid. But I'm sure there will be others less reluctant about it and glue together any super mega hyper GS machine you can dream of. We are slowly reaching for the stars here.

[zaphod77]

That's more than fair. i'm just genuinely wondering what else would improve GS?

There is a fault in the gs implementation. gs delay does not seem to actually work. But i can see no obvious way to fix that.

[NightFright2k19]

The patch is ready now. Feel free to test it extensively and provide feedback!

Highlights, taken straight from the commit changelog:

Sound conversion

• Element HPF (MU100/MU128/MU1000) baked into filtered multisample copies; MU100 cutoff read from element byte +69 (was ignored)
• Drum keys: HPF, level offset, no-hold attack mode for instant attacks, velocity pitch/LPF sense via generated ext drum voices
• Voices with 3/4 elements (22 MU1000 voices) folded into two elements instead of dropping elements 3/4 (elemreduce.py)
• Per-member wave start offset and percussive amp EG baking for merged elements (fixes Tim'sSet +20-33 dB above key 60)
• Rising decay 2: decay 1 level raised to 64, the DLL ended these notes below that level (Lite Org, WireLead, ...)
• HPF copies now follow the coarse-tuned key range
• MU80: program map written for duplicated banks (MSB 126/127)

DLL patches (all models)

• Missing effect types mapped to the nearest available type
• Effect return levels scaled per type, updated on type change
• Effect fade-in after type change shortened from 0.3-1 s to 80-90 ms
• Drum setup EG offsets for ext drum voices no longer doubled
• Full patch: 768 multisamples (3 pages), 30-bit drum sample addresses
• Per-model bitmaps, names, string table and version info

Usage

• New --embed switch: table and wave data stored inside the DLL
• ROMs also read from ./roms (incl. subfolders)
• All detected models converted in one run, DLLs named syxg.dll
• Wildcard expansion, SXG_NO_PAUSE, Python 3.12+

Checked against the S-MU2000 and MU1000 recordings, and MU50 against Yamaha's own S-YXG50 table (identical voice/drum parameters). Wave data grows mainly due to the HPF copies (MU1000: 51 -> 87 MB).

Conversion should now really be as easy as it can be:

• Place all your ROMs in a "roms" subdir within the script directory (can also be placed in subdirs for better organization)
• Place a copy of syxg50.dll in the script root dir (can be the one with embedded wavetables or with external ones)
• Execute the Python script: python main.py syxg50.dll --embed (for embedded wavetables)
• Script will generate all DLLs with proper naming and individual equalizer labels/names/internal IDs

Details are outlined in the updated readme.

[zaphod77]

I like that you added the new bitmaps.

did you also edit the internal names?

doing the mass conversion now.

[NightFright2k19]

All IDs are changed internally. The MU50 is a small exception, will be named syxgmu50.dll since syxg50.dll is already taken. Also keeps the "S-YXG50" naming on the top right of the equalizer panel. Internal labeling is otherwise adjusted as for the all the other MUs.

[zaphod77]

Awesome. now i just wish i could figure out why the variation sometime dies through savihost, but that's not a fault in the conversion. it seems to happen with savihost through web midi, regardless of virtual midi cable used. but it happesn with the original dll as well.

I'd like to see one more conversion. ones that only grabs the samples used by an mu50 or 80 from the higher models. actually two versions. one with the basic map and one with the native map. this would create smaller table sizes, and would fulfil the goal of the original hi-end project. use the same instruments, but better samples.

Of course, this idea will only be useful if that actually produces an increase in sample quality versus mu80 conversion. it may be that the mu80 conversion, which is about as big as the HiEnd project, is the actual HiEnd.

This is now a very impressive backport.

[NightFright2k19]

With SaviHost I cannot assist much since I'm not using it. Might be a limitation its author isn't yet aware of, maybe? In my test runs nothing of the sort occurred.

With these adjustments I've burnt through most of my Claude Opus 5.5 contingent for the month. It did the work of several months within the matter of days. Nevertheless: Excessive testing from my side was required and right now I'm pretty exhausted, tbh.

Your idea to create a "low-end hi-fi hybrid" seems a bit redundant and useless to me, though. We have the MU90 for that already. To clarify why I think it's bad idea:

1. The effects are already the same across all models.
   All effect enhancements are contained in the DLL, not in the table: replacement types, return levels, shortened fade-in and drum EG offsets. Every converted DLL receives these patches, whether it’s the MU50 or the MU1000. So the MU90 DLL already has the same effects capability as the MU1000 DLL. However, the S-YXG50 engine cannot replicate what the real MU100+ can do — namely, insertion effects and a few additional variation types — on any model. You can’t achieve this even by combining them.

2. The Element HPF is part of the voices, not the effects.
   The high-pass filter is a parameter of individual voice elements and applies only to sounds that Yamaha has retuned starting with the MU100. Verified: All 783 MU90 voices are also included in the MU128 (as “MU Basic”), and none of them use the HPF there.

If you were to apply the HPF from the new “#” voices to the MU90 sounds, you’d end up with a sound that doesn’t exist on any device. The MU90 sound would then be neither the original nor the MU1000.

Moreover, the HPF is precisely what makes wavetables so great: filtered copies of samples — about 33 MB for the MU1000. Getting a smaller wavetable with an HPF is therefore an illusion. For every voice with an HPF, those copies have to be created again.

What WOULD be doable:
MU100+ builds which have the MU-Basic/MU-Native modes integrated and could be toggled with a switch through the DLL setup menu. That's one thing we can still think about for a future update. It would make separate builds for the two modes needless and the wavetables would only grow minimally in size.

[zaphod77]

Yes, if you can hack in a toggle between native and basic maps, that would probably be useful. but that will be a futire project.

So the mu basic map is actually the entire mu 90 map, plus the new instruments? The docs say that it's only for bank zero.

So just loading mu90 is honestly a better option than using the mu-basic map with a later synth, because the patches are actually completely identical?

Then yeah, the basic map thing is actually pointless, because nothing would actually be composed for mu100 or later with basic map. My thought was that later devices would have higher quality versions of the basic map, but if that's not actually the case, ther;s no point, and you should just use mu-90 and be done with it.

This leaves the only possible use of a shrunk table would be just including the mu2000 instruments that have mu basic equivalents to make a smaller VSTi.

GS honestly handles this part better, because you can use bank select LSB to say which device you actually composed it for, and if the current device has a backwards compat mode for it, it will use it.

[NightFright2k19]

Looks like the MU mode switch was easier to implement after all. On top of it, I found an error in the DLL conversion for the MU50. The wrong wavetable name was chosen, making the plugin non-functional.

Preview for the new menu checkbox (only available in MU100 or higher):

Changelog:

• MU100/MU128/MU1000 tables now contain both voice maps (MU Native + MU Basic) in one table; the wave data does not grow (MU100 +70 banks, MU128 +83 banks/32 voices, MU1000 +86 banks/32 voices)
• New DLL patch: checkbox "MU Basic voice map" on the Setup page, takes effect at the next program change, stored as [Config] MUBasic=0/1 in the DLL's ini; works with external and embedded (--embed) tables, hidden for tables without a second map
• Removed --mu-basic (ignored with a note); no separate ...BX table sets any more
• MU50: the string table now names SXGMU50a1.TBL instead of SXGBIN41.TBL, so the DLL loads without a SoftSynth ini entry (embedded builds, hosts that don't find the ini)
• README: voice map switch, ini key, patch sites, MU50 fix

[NightFright2k19]

Some last fine-tuning to make it work properly.

Changelog:

• The MU Native/MU Basic setting is now part of the VST chunk (3 bytes appended to the bank/program chunk), saved and restored by the host like the other Setup options; older chunks are still accepted
• The DLL no longer writes an ini; embedded DLLs stay a single file
• [Config] MUBasic=1 in the ini is optional and only read (start value); Set Defaults returns to the start value
• README: patch sites (getChunk 0x2B50, setChunk 0x2BB0), saving behavior

[NightFright2k19]

Small improvements for four GS voices in the MU50 table.

Changelog:

• MU50: ext drum voices are now read from the program ROM's own table (87 x 32-bit voice addresses at 0x3B3CA, location from TaleTN's MUTable) instead of a hand-made list
• The old list had two used entries wrong: GS C/M Kit keys 81/102 and SFX Set keys 57/78 played SynMalet / Bird 2 instead of FootStep / Tweet
• Rebuilt MU50 table differs only in these 4 keys (all voice slots and other drum keys unchanged)
• README: MU50 section, changelog, MUTable credit; corrected README/code notes (its scaling tables are in the ROM; same result as MU1000, so the MU1000 set is still used)