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