More docs.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@7577 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
mahlzeit
@@ -0,0 +1,25 @@
|
||||
<HTML>
|
||||
<BODY>
|
||||
|
||||
<H3>How libmidi1 works</H3>
|
||||
|
||||
<P>Midi1 is implemented on top of midi2, which means that libmidi.so depends on libmidi2.so to do the real work. BeOS versions earlier than R5 did not include a midi_server, because midi1 itself did not need it. (A server is only really useful if data must be shared between teams, something that midi1 did not allow.)</P>
|
||||
|
||||
<P>Midi2 is backwards compatible with midi1: The old libmidi.so still exists so that applications using the old API will run (providing binary compatibility). The old <CODE>BMidiPort</CODE> object is now a wrapper that uses the new <CODE>BMidiRoster</CODE> to allow connections to any published MIDI producer or consumer. Published MIDI objects are presented to the old MIDI apps as if they were physical MIDI ports.</P>
|
||||
|
||||
<P>Here is a very nice picture of how <CODE>BMidiPort</CODE> works:</P>
|
||||
|
||||
<P><IMG ALT="" SRC="midiport.png"></P>
|
||||
|
||||
<H3>The softsynth</H3>
|
||||
|
||||
<P>The General MIDI synthesizer is implemented in <CODE>BSoftSynth</CODE>. This is a private class (not usable outside the API). It is not a real <CODE>BMidiEndpoint</CODE>, so you will not see it appear on Patchbay. I did this for simplicity's sake, for backwards compatibility (this is how the R5 synth worked too), and because we will have to give the Midi Kit a complete makeover for R2 anyway.</P>
|
||||
|
||||
<P>The <CODE>BMidiSynth</CODE> and <CODE>BSynth</CODE> classes delegate most of the work to <CODE>BSoftSynth</CODE>. Not all of their methods are implemented, since some of them are very obscure. It would be a lot of work to figure out what they do, while it is likely that no applications use them anyway. However, <CODE>BMidiSynth</CODE> and <CODE>BSynth</CODE> should perform most common tasks without problems.</P>
|
||||
|
||||
<P><CODE>BSamples</CODE> doesn't do anything; its functions are mostly empty. In other words, with the OpenBeOS Midi Kit you cannot push waveform data into the output of the softsynth.</P>
|
||||
|
||||
<P>For simplicity's sake, <CODE>BMidiSynthFile</CODE> is implemented using <CODE>BMidiStore</CODE>, since the latter already knows how to parse Standard MIDI Files. Duplicating that functionality elsewhere would be pointless. However, this makes the behavior of our <CODE>BMidiSynthFile</CODE> a little different from what the BeBook says — as long as your applications are written properly, you shouldn't notice any differences.</P>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -0,0 +1,43 @@
|
||||
<html>
|
||||
<body>
|
||||
|
||||
<h3>OpenBeOS Midi Kit TO DO List</h3>
|
||||
|
||||
<p>May 14, 2004</p>
|
||||
|
||||
<h3>Big Things</h3>
|
||||
|
||||
<p><b>Softsynth.</b> We need a General MIDI softsynth. We can either write it ourselves or port an existing one. I was thinking about FluidSynth (formerly IIWU Synth) since it is very good and supports SoundFonts, but I had trouble writing a BeOS audio driver for it. FluidSynth is also GPL, but that is not a major problem. Must be implemented in the BSoftSynth class from libmidi.so</p>
|
||||
|
||||
<p><b>Test libmidi.so</b> The BMidiSynth, BMidiSynthFile, BSamples, and BSynth classes have been implemented and briefly tested. They seemed to work fine, even with the R5 MidiPlayer app. However, the only proper way to test them is with sound output, and for that we need the softsynth.</p>
|
||||
|
||||
<h3>Small Things</h3>
|
||||
|
||||
<p><b>BMidiStore is slow.</b> 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.</p>
|
||||
|
||||
<p><b>MPU401 kernel module.</b> 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.</p>
|
||||
|
||||
<p><b>BSynth::GetAudio()</b> This function fills up a user-provided buffer with recent sample data. Mostly used to display scopes and other visual trickery. Whether we will support this or not depends on the capabilities of the softsynth back-end.</p>
|
||||
|
||||
<p><b>Watching /dev/midi for changes.</b> 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.</p>
|
||||
|
||||
<p><b>BMidiSynthFile::Fade()</b> 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.</p>
|
||||
|
||||
<p><b>Must be_synth be deleted when the app quits?</b> 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:</p>
|
||||
|
||||
<blockquote><pre>namespace BPrivate
|
||||
{
|
||||
static struct BSynthKiller
|
||||
{
|
||||
~BSynthKiller()
|
||||
{
|
||||
delete be_synth;
|
||||
}
|
||||
}
|
||||
synth_killer;
|
||||
}</pre></blockquote>
|
||||
|
||||
<p><b>midiparser kernel module.</b> 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.</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user