Okay, this MUNT thing might not actually be all that bad... for now at least.
I ran into the problem that the host application is made with Qt, which I'm not familiar with, and trying to build the project wasn't successful on the first try.
However, the driver part has MSVC project files, and I could build that. So I've now basically made my own copy where I searched and replaced all MT32 for FB01, and now I have a driver of my own, which is registered as a MIDI device, and is picked up by the MUNT host.
The actual emulation is still MT-32 currently, but I can now work on gutting the MT-32 part and putting my VFB-01 code in there instead, and we should be in business.

Great to hear Scali! I love stories like this 😀.

JAL

P.S. Found your site again, listening to the Doom AdLib music 😀.

jal wrote:

Great to hear Scali! I love stories like this 😀.

Are you the same jal who thought that 8088 MPH was not impressive over at osnews.com? 😀

Yup, that's me 😉. I loved the 8088mph stories though 😀.

JAL

Hum, MUNT is weird...
If you start the MUNT application, it actually overrides the MIDI driver.
It seems the MIDI driver itself doesn't actually work though.
That is, it receives the MIDI data, and it outputs wave data... But the MIDI data is never passed to the emulation part, it seems, so it always plays silence.
The MUNT application itself then is nothing but a wild goose chase. It has its own emulation built-in, so you always get MT-32, regardless of what drivers you have installed.
I'll have to find where it is that the MUNT application sends the MIDI data to the emulation core, and see why that is missing from the standalone driver, and try to get that fixed.

I'm confused... why do you need MUNT? I've been looking a bit how the GUS implementation is done in dosbox. It looks like it only needs a "MixerChan.Install(GUS_CallBack,GUS_RATE,"GUS")" and the callback calculates the next MIXER_BUFFER_SIZE samples and sends them back to the channel mixer via "gus_chan->AddSamples_s32(len, buffer[0])". Dosbox takes care of the rest to output the sound.

WAIT A MINUTE!! Have a look at the mame code in "/src/devices/bus/isa/ibm_mfc.c"... DO YOU SEE WHAT I SEE?!

Success... sortof!
For some reason, the version of the code in Synth.cpp that I had was:

1const MidiEvent *MidiEventQueue::peekMidiEvent() {
2	OutputDebugString("peekMidiEvent\n");
3	return NULL;
4	//return isEmpty() ? NULL : &ringBuffer[startPosition];
5}

So it only output a debug message, but never actually sent the events from the queue back to the emulator.

I now get MIDI sound playing through the VFB-01. It's just a bit... crackly.
But hey, at least it's a start 😀

lchiocca wrote:

I'm confused... why do you need MUNT?

I want to make a generic FB-01 emulator, which acts as a MIDI device, just like how MUNT gives you an MT-32.
People have objections against integrating MT-32 emulation directly into DOSBox as far as I understand, and for IMFC/FB-01 it probably would be no different.
For me it doesn't really matter, I need to write the code anyway. Whether I package it into a separate MIDI driver or integrate it into DOSBox doesn't matter.
I just think that a separate FB-01 emulator can be useful outside of DOSBox as well.

lchiocca wrote:

WAIT A MINUTE!! Have a look at the mame code in "/src/devices/bus/isa/ibm_mfc.c"... DO YOU SEE WHAT I SEE?!

Ah yea, it's a bit late for that now, I'm afraid 😀
This seems to be mostly a stub... The most obvious todo is of course "YM-2164", which I'm already working on.
The other one, "MIDI", I have already solved to a certain degree. Well enough to make it work with Sierra games at least.

I think the crackling is to do with how it handles note on/off commands.
If I play a note-on multiple times, it just gives a crackle after the first time, and the original note continues playing.
Might have to do with how polyphony is implemented in the emulator.

Ah, found it... it doesn't necessarily render buffers of fixed size, but can render up to the next sample where a MIDI event occured.
I didn't do the calculations for that correctly, needed to add a factor 2 to account for the fact that the sample count was in stereo samples, where the VFB-01 code expects single sample counts.
Now it works acceptably... still distorting a tad, but I guess that's just the YM2151 emulation itself. When I load a different voice configuration, it's less apparent.

Here's some recordings...
First, Leisure Suit Larry 3, played via DOSBox and my fb01emu driver based on the MUNT sources: https://soundcloud.com/scali/lsl3
Second, playing STRIVING.MID via my own MidiPlay test application, via the fb01emu driver: https://soundcloud.com/scali/striving

Nice! If you can get silpheed or space quest 3 to sound like the originals I would be severly impressed 😉 http://www.crossfire-designs.de/index.php?lan … undcards&page=6

lchiocca wrote:

Nice! If you can get silpheed or space quest 3 to sound like the originals I would be severly impressed 😉 http://www.crossfire-designs.de/index.php?lan … undcards&page=6

Haha yes, the fun is only just starting now...
I've only set up the scaffolding so far: Getting MIDI data from a game's IMFC driver to a MIDI device, and making a MIDI device that hosts a YM2151 emulator.
It seems that the VFB-01 code for the regular MIDI commands is doing a good job. Note pitch, volume and panning seem to work as expected.
I have no idea how accurate its polyphony code is at this moment though, or whether it implements the functionality of the real FB-01 where you can allocate a given number of voices to each instrument. That will be very important for how Sierra uses the IMFC.

The Windows MIDI driver has separate paths for simple MIDI commands and larger buffers (basically SysEx stuff). I hadn't connected the SysEx part up to the VFB-01 emulator yet.
I'll do that now, but it seems it only supports a single command currently, so I don't expect too much to happen at first.
The fun will be in implementing all SysEx commands and allowing the IMFC drivers to do the low-level tweaking of the FM parameters.

Anyway, is anyone interested in joining the fun? Should we set up a source repository somewhere, so that people can view and work on the FB-01 emulation code?

Guess who 😀. github would be a good starting point

Scali wrote:

lchiocca wrote:

Scali, I just had a look at the mame code for the ym2151... All the changes starting with the objectifying commit can be discarded. You could use the ym2151 from mame commit id ec5b9deadee9a2f95e0691f7246a8f4663ba3ba9. But you could also use the real C version from commit 18188cb13bc11ba743d19e28125c6d8ab940fb70 as well. There were no code changes that affected the processing.

Thanks, that's at least something.

No, but there is a license change.

The ym2151.c from commit 18188cb13bc11ba743d19e28125c6d8ab940fb70 is still under the classic "MAME license". This is effectively "BSD 3-clause license with a non-commercial use clause". This license is not compatible with the GPL or OSI-approved and cannot be combined with other GPL code in GPL projects due to that clause.

The ym2151.c from commit ec5b9deadee9a2f95e0691f7246a8f4663ba3ba9 had its license changed by its author Jarek Burczynski to GPL-2.0 or higher. This is therefore compatible with other GPL projects. This does not retroactively apply to previous versions' code.

... I expect I'm gonna get a massive eye-roll from Scali, but just being pedantic...

Stiletto wrote:

... I expect I'm gonna get a massive eye-roll from Scali, but just being pedantic...

No, it's good that you bring up the subject of licensing actually.
I did notice that there was a change with "GPLv2" being added (the earlier version had '???' as a license).
Up to now, I had just been hacking away at various pieces of code, trying to see what was happening where, and how to make it work.
Now that most things are in place, and I am preparing to put it up on Github, it's good to have a closer look at the licensing.
I believe we are dealing with 4 separate open source projects here, so far, which I have turned into a 5th project of my own:
1) DOSBox: GPLv2 license
2) VFB-01: GPLv2 license
3) YM2151 code from MAME: In its original form in VFB-01, no specific license, current version GPLv2
4) MUNT: GPLv2 license

I suppose it makes sense to just stick with GPLv2 for everything.
The thing I am personally more worried about at the moment is the way code is intertwined. That is, the VFB-01 project uses some MAME-code, but it is not physically separated from the rest of the code. I think having some subdirectories to mark code coming from different projects may make things easier in the future. You can immediately find all the files that were taken from MAME, and compare them against later MAME versions.

Likewise, my current hackjob of the MUNT driver just put the relevant VFB-01 files directly into the project directory.
I suppose the MUNT driver was never specifically designed to be a re-usable 'shell' for MIDI device emulators, so the code in there is also intertwined between the WinMM-related parts and the MT-32 code. When I pruned the MT-32 and grafted the VFB-01 into there, I basically removed most of the MT-32-specific code. I could put the VFB-01 code in a separate directory again. I could also rework the MUNT driver somewhat more, so that the driver is fully abstracted from the emulation layer, and the MT-32 emulation will follow the same pattern.
But I think I'll leave that for now. I'll just concentrate on cleaning up the driver and FB-01 version first.

I hope the DOSBox people will accept the above IMFC patch into the main SVN. It may not be fully functional yet, but it would be nice if it is already integrated in the main SVN, so we can build on it from there. It will then find its way to all other forks of DOSBox as well.

The library elements of MUNT are LGPL licensed.

Scali wrote:

Stiletto wrote:

... I expect I'm gonna get a massive eye-roll from Scali, but just being pedantic...

No, it's good that you bring up the subject of licensing actually.
I did notice that there was a change with "GPLv2" being added (the earlier version had '???' as a license).

Okay, thanks. Currently I sit on the "administrative board" for MAME so it would be good for me to stick up for the project like in this instance. DOSBox-dev team had run afoul of our former weird license eons ago (partially my fault) and so I don't want to see people making the same mistakes. (We've since cleared all that up.)

"(the earlier version had '???' as a license)" this was actually a placeholder header as MAMEdev pursued our months-long relicensing project. Any code with "???" listed as "license" was technically still under the traditional MAME license at that time, until we heard otherwise from our developers. Prior to the relicensing project, such headers didn't exist, and only a select few developers dual-licensed their code, so almost all prior code was licensed "MAME license". Anyhow, as multiple contributors reported back with a preference, we attempted to find consensus where possible, and relicensed code file-by-file. In the end, over 92% of MAME code got relicensed to standard BSD 3-clause license, but there were some exceptions, FM synth emulation code being one of those exceptions (it went to GPLv2+).

Compartmentalizing like you say is a good idea. MAME itself files most external library code under "3rdparty", and this helps either a. Linux/BSD distros that prefer to use system libraries and b. updating said libraries when necessary asynchronously. But for you, for instance, we have someone on our team who plans to update every FM synth core based upon information gained from chip decaps (previously it's been mostly reverse-engineering based on documentation and readings from test rigs) and do a complete rewrite, which should make for an even deeper level of accuracy, and it might be good for you to be able to update should that project ever finish. (His to-do list's pretty monstrous so it may be a while...)

gdjacobs wrote:

The library elements of MUNT are LGPL licensed.

That brings up an interesting point...
My FB-01 emulator will be a DLL, which you would use in Windows ('link to'?)... so non-GPL code.
Do you have to use LPGL in that case, or is 'regular' GPL valid for this use-case?
And in the case you use LGPL, how does that work for other parts of the code? The YM2151 code and VFB-01 code are normal GPL.
My FB-01 DLL will be a 'derivative work' of these, but I will distribute their full sourcecode with my modifications.
But part of that code would then be MUNT-code that is under LGPL, and the DLL as a whole may have to be distributed as LGPL.
Is it valid to have these licenses co-exist in a single project like this?

I suppose... worst case I have to distribute under GPL. I don't think that by itself is a problem for Windows binaries.
But possibly it might mean that in theory you may only use other GPL programs to use the driver (which you can't enforce), since people may argue that they are 'derivative works'.
In the case of DOSBox and its IMFC interface, we'd be fine, as it is GPL anyway.
I personally don't think it's a 'derivative work' any more than eg two programs communicating via a network socket (where it is commonly accepted that programs connecting to a GPL network program do not have to be GPL'ed themselves). After all, MIDI is basically a network protocol as well, and you're merely sending bytes over the line. You're not linking the FB-01 emulator directly to the DOSBox binary. It's done via Windows' MIDI mapper.