71 lines
3.3 KiB
ReStructuredText
71 lines
3.3 KiB
ReStructuredText
|
Midi Kit TO DO List
|
||
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
**Communicating with device drivers.** The midi_server already has a
|
||
|
|
pretty good parser that turns an incoming stream of bytes into MIDI
|
||
|
|
messages. It uses read() to read a single byte at a time. However, the
|
||
|
|
midi_driver.h file lists a number of ioctl() opcodes that we are
|
||
|
|
currently not using. Should we? In addition, do we really need to spawn
|
||
|
|
a new thread for each device? The R5 midi_server doesn't appear to do
|
||
|
|
this. An optional feature is to implement "running status" for MIDI OUT
|
||
|
|
ports (i.e. when writing to the device driver). This would be pretty
|
||
|
|
simple to add.
|
||
|
|
|
||
|
|
**BMidiStore is slow.** Importing a Standard MIDI File of a few hundred
|
||
|
|
kilobytes takes too long for my taste. The one from R5 is at least twice
|
||
|
|
as fast. It is important to speed this up since BMidiStore is used by
|
||
|
|
BMidiSynthFile to play MIDI files. We don't want games to slow down too
|
||
|
|
much.
|
||
|
|
|
||
|
|
**MPU401 kernel module.** Greg Crain did a great job of writing this
|
||
|
|
module. Unfortunately, we only know how the v1 interface works; v2 is
|
||
|
|
not documented. What's worse, most Be R5 drivers use v2. Currently, the
|
||
|
|
module returns B_ERROR when a device is opened with v2. Is this going to
|
||
|
|
be a problem for us? It depends on whether we will be able to use the
|
||
|
|
closed-source Be drivers with our own kernel — if not, then we can
|
||
|
|
simply ignore v2.
|
||
|
|
|
||
|
|
**Watching /dev/midi for changes.** Whenever a new device appears in
|
||
|
|
/dev/midi, the midi_server must create and publish a new MidiProducer
|
||
|
|
and MidiConsumer for that device. When a device disappears, its
|
||
|
|
endpoints must be removed again. Philippe Houdoin suggested we use the
|
||
|
|
device_watcher for this, but R5 doesn't appear to do it that way. Either
|
||
|
|
it uses node monitoring or doesn't do this at all. Our midi_server
|
||
|
|
already has a DeviceWatcher class, but it only examines the entries from
|
||
|
|
/dev/midi when the server starts, not while the server is running.
|
||
|
|
|
||
|
|
**BMidiSynthFile::Fade()** Right now this simply calls Stop(). We could
|
||
|
|
set a flag in BMidiStore (which handles our playback), which would then
|
||
|
|
slowly reduce the volume and abort the loop after a few seconds. But we
|
||
|
|
need to have the softsynth in order to tune this properly.
|
||
|
|
|
||
|
|
**Must be_synth be deleted when the app quits?** I have not found a word
|
||
|
|
about this, nor a way to test what happens in R5. For example, the
|
||
|
|
BMidiSynth constructor creates a BSynth object (if none already
|
||
|
|
existed), but we cannot destroy be_synth from the BMidiSynth destructor
|
||
|
|
because it may still be used in other places in the code (BSynth is not
|
||
|
|
refcounted). We could add the following code to libmidi.so to clean up
|
||
|
|
properly, but I don't know if it is really necessary:
|
||
|
|
|
||
|
|
::
|
||
|
|
|
||
|
|
namespace BPrivate
|
||
|
|
{
|
||
|
|
static struct BSynthKiller
|
||
|
|
{
|
||
|
|
~BSynthKiller()
|
||
|
|
{
|
||
|
|
delete be_synth;
|
||
|
|
}
|
||
|
|
}
|
||
|
|
synth_killer;
|
||
|
|
}
|
||
|
|
|
||
|
|
**midiparser kernel module.** midi_driver.h (from the Sonic Vibes driver
|
||
|
|
sample code) contains the definition of a "midiparser" kernel module.
|
||
|
|
This is a very simple module that makes it easy to recognize where MIDI
|
||
|
|
messages begin and end, but apparently doesn't tell you what they mean.
|
||
|
|
In R5, this module lives in /boot/beos/system/add-ons/kernel/media. Does
|
||
|
|
anyone use this module? Is it necessary for us to provide it?
|
||
|
|
Personally, I'd say foggeddaboutit.
|