a5061ecec5
An effort was started some time ago to consolidate all internal documentation in the git tree. However, this was just an accumulation of files in various formats without any strucutre or way to browse it, which results in no one even knowing that we have docs here. This converts most of the files to restructuredtext and uses Sphinx to generate an HTML browsable user manual (with a table of content and a first attempt to put things in a global hierarchy). There are almost no changes to the documentation content in this commit (some obviously obsolete things were removed). The plan is to get the toolchain up and running to make these docs easily available, and only then see about improving the content. We can migrate some things off the wiki and website, and rework the table of contents to have some more hierarchy levels because currently it's a bit messy. Change-Id: I924ac9dc6e753887ab56f18a09bdb0a1e1793bfd Reviewed-on: https://review.haiku-os.org/c/haiku/+/4370 Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
51 lines
2.2 KiB
ReStructuredText
51 lines
2.2 KiB
ReStructuredText
How libmidi1 works
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
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.)
|
|
|
|
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 ``BMidiPort`` object is now a wrapper that uses
|
|
the new ``BMidiRoster`` 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.
|
|
|
|
Here is a very nice picture of how ``BMidiPort`` works:
|
|
|
|
|image0|
|
|
|
|
The softsynth
|
|
~~~~~~~~~~~~~
|
|
|
|
The General MIDI synthesizer is implemented in ``BSoftSynth``. This is a
|
|
private class (not usable outside the API). It is not a real
|
|
``BMidiEndpoint``, 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.
|
|
|
|
The ``BMidiSynth`` and ``BSynth`` classes delegate most of the work to
|
|
``BSoftSynth``. 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,
|
|
``BMidiSynth`` and ``BSynth`` should perform most common tasks without
|
|
problems.
|
|
|
|
``BSamples`` 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.
|
|
|
|
For simplicity's sake, ``BMidiSynthFile`` is implemented using
|
|
``BMidiStore``, 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 ``BMidiSynthFile`` a little
|
|
different from what the BeBook says — as long as your applications are
|
|
written properly, you shouldn't notice any differences.
|
|
|
|
.. |image0| image:: midiport.png
|
|
|