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