Status update

Hi all,

Warning: this is a long email :-). In the last few days, I fixed a number=
 of
outstanding issues with the Midi Kit, and I would like to let you know wh=
at
I did and where we stand now.

THE SOFTSYNTH (PART 1)

Jerome Leveque already wrote the beginnings of a softsynth. I took his
classes and used them to finish BSynth, BMidiSynth, BMidiSynthFile, and
BSamples. These don't do much themselves; they delegate most of the work =
to
a new class, BSoftSynth. BSamples is empty, because we don't need to supp=
ort
its obscure behavior. Note: We do not have an actual synthesizer yet;
BSoftSynth is still empty.

Jerome, this is different from what you wanted to do. BSoftSynth is a
replacement for your SynthConsumer class. If you are still interested in
working on the softsynth, you should use BSoftSynth for that. I did not u=
se
your MidiFileProducer and MidiFileConsumer. Instead, I used BMidiStore to
implement BMidiSynthFile. But it was good to have your code, because it
saved me a lot of work :-) Thanks.

I briefly tested these classes and they seemed to work fine (even with th=
e
R5 MidiPlayer), but without sound it is very hard to tell whether they
really really do what they are supposed to. When the softsynth is finishe=
d,
we will be able to test them more carefully.

MPU401 AND THE KERNEL MODULES

I know that it has been in the CVS for quite a while now, but I finally
looked over the MPU401 module code that was submitted by Greg Crain :-)
Thanks again for your contribution, Greg. The missing "v2" interface supp=
ort
is not a major disaster, as far as I am concerned. Our kernel may not be
binary compatible with the old R5 drivers anyway, in which case we will h=
ave
to rely on new drivers -- none of them is likely to use v2.

I think we will drop the midi parser kernel module. As far as I can tell,=
 no
one is using it, so why bother supporting it. It looks like something tha=
t
was intended for the Media Kit anway ;-)

DRIVERS AND THE MIDI PARSER

A little while ago, Christian Packmann contributed an improved parser for
raw MIDI streams. I integrated this with the midi_server. This code is us=
ed
to read MIDI messages from from device drivers, i.e. from MIDI IN ports. =
Now
it should handle "running status" and "realtime data in non-sysex message=
s"
properly. Thanks Christian! I tested this code in a separate application =
and
it worked very well; I hope it works as well in the midi_server :-) I did
make a few small changes here and there, but nothing extensive.

THE SOFTSYNTH (PART 2)

I have been looking at FluidSynth, an open source (LGPL) software
synthesizer (http://www.fluidsynth.org). It is apparently a pretty good
synth and it would save us a lot of work if we could use this instead of
writing our own. I managed to do a quick-n-dirty port to BeOS, although t=
he
audio driver I made is pretty bad. In the coming weeks, I will try to do =
a
clean port (possibly stripping out everything we don't need, such as
DirectSound drivers). If I can get it to work, I will integrate it with
BSoftSynth and we should be ready to rock. However, I may have to ask you
guys/gals for some assistance with the audio driver.

Jerome, I hope you don't mind that I am looking at an alternative for you=
r
synth. I know that you are very busy and don't have a lot of time to work=
 on
it. Ideally, we would like to be able to demonstrate a fully working Midi
Kit at WalterCon (mid June this year) and for that we need the synth. Of
course, if yours turns out to be better, we will use that instead ;-)

Cheers,
-Matthijs