Here, I just played a scale C-D-E-F-G-F-E-D-C twice, with both hands:

I have a similar problem in linux: cat /dev/midi DOES give MIDI data, but it loses *whole bytes* from the stream of data sent by the keyboard I have attached to the computer. It doesn't do that in windows, from what I can see. Its probably an ALSA bug in the MIDI input system for OPL3-SA2 cards (like mine).

Now that may be interesting, but its completely useless to other people. HOWEVER: I found a workaround for this problem. It DOESN'T let me use my MIDI keyboard in linux, but it's the next best thing, and I think its JUST what runderwo was looking for:
http://helgo.net/simon/clavier/

Lord Nightmare

That is strange. Actually, I use a MPU-401AT that my keyboard is attached to. Can you post an example of a stream from your keyboard?

BTW, thanks for the link to clavier, looks like it will be useful.

Next step, I created a library with some C<-C++ glue code that gives me both C and C++ interfaces to the emulator. I needed a C interface for timidity. Only minor modifications were needed to the original files, which is mostly the way I wanted it to be (so I don't have to maintain a huge patch set every time there is a new release).

Alex, is the emulator threadsafe besides the init code? I notice there are global tables in the cpp file, but they seem to be modified only during InitTables (unles I'm blind).

Also, do you plan on releasing your modified Dosbox sources since you distributed the modified binary? I'm curious to see how Dosbox is calling the emulator, esp where it has the emulator render to a buffer. (Also I think you are supposed to because of the GPL)

Actually, until I removed it from the gigantic header file, it was perfectly integrated into DosBox. Now, I've made a new, smaller midi_mt32.h header file that does the same functionality but through all the exposed commands. The delay in my new version, however has been my frustration with optimization. My emulator just isn't fast enough. My goal is to be able to have it render sound at 44000hz without skips on a 550Mhz machine. I know its possible. I've got some ideas, now I just have to implement them.

Awesome. Since I have a PIII-550, I'd be more than happy to send you reports of how the next version works for me 😁 I'd be happy running it at a lower rate like 22050 though just for the ability to use it.

What parts of the emulation are requiring the most processing power? What kinds of tricks have you thought of? Have you considered assembly optimizations, or CPU-specific optimizations (like taking advantage of PPro or PII and higher instruction sets)? Or maybe using DirectSound for the output? Just throwing some ideas out in hopes that it will help inspire you 😉

My emulator just isn't fast enough. My goal is to be able to have it render sound at 44000hz without skips on a 550Mhz machine. I know its possible. I've got some ideas, now I just have to implement them.

Is that with or without the SSE/3DNow vector instructions? I plan to implement those in gcc asm too, once I can even get the C version to play something. 😁

Probably with. At this very moment I'm giving the rendering system a major overhaul to give it big optimization boost. After I rewrite it, tons of stuff will be ideal for MMX optimization too.