Reply 120 of 263, by Scali
Studying the code some more, the implementation is indeed not like a real FB-01 at all.
It uses a bruteforce approach where it allocates one YM2151 emulator for each MIDI channel, and does a 1:1 mapping.
Which also means that you get a polyphony of 8 notes per channel.
Apparently the VFB-01 project was never more than 'make something that can sound FB-01-like'. Good enough if you want to use it as a sound module when composing music, but not very useful if you want an actual replacement for the real thing.
Likewise, it implements its own SysEx command for setting voice parameters, but no actual SysEx commands for the real FB-01.
I think my next tasks will be:
1) Set up some stubs for all the FB-01 SysEx commands, so they can be implemented later
2) Rewrite the MIDI-to-YM2151 code so that it uses the same mapping strategy as the real FB-01: You have instruments which can have a polyphony of 0 or more, with a maximum of 8. Each instrument can be assigned to 0 or more MIDI channels. Oh, and don't forget that you also have low and high note ranges for each voice, so you could have multiple voices on the same MIDI channel.
Once the remapping works, I can at least implement the SysEx commands that manipulate the mapping or that manipulate either an instrument directly, or manipulate an instrument through an associated MIDI channel.
So, while we have sound, it's not actually the 'right' sound yet 😀
It will still take some work before the SysEx commands can be implemented, and the thing can start behaving as a real FB-01.
Another thing that I wonder about is the way the FB-01 implements 'streaming' SysEx commands.
It has certain 'list' commands that can contain a number of command sequences, which the real thing will play in realtime. It includes things like custom note on/off commands and such, so being realtime is very important (the Sierra games actually upload their voice data this way, which leads to the large 6k SysEx commands that broke DOSBox earlier).
The way most software implements MIDI on Windows is to send SysEx as simple 'long messages' via the API (which is why DOSBox broke).
That isn't going to work in this case.
For the voice data upload I already had to make a workaround, since that particular SysEx command was only implemented on the IMFC, not on a real FB-01. So I capture the 'streaming' SysEx command when it comes in on the IMFC interface, and I split it up into smaller SysEx commands for the FB-01.
I suppose I could also do that for other types of 'list' commands, so that at least DOSBox works correctly (albeit at a slightly higher bandwidth requirement for MIDI).
But on the receiving end, the FB-01 should be able to handle it as well. I'm not sure at this moment whether the MUNT MIDI parser can do this. First impression was that it cannot.
The parser would need to be stateful: when you receive a 'long' MIDI message, it is not necessarily a complete SysEx command, it could be a fragment. Then the parser would need to keep streaming the data to the backend until it reaches the end of the SysEx command. Basically the same trick as what I implemented in the IMFC code.