Version 1.0 written by Ben Loftis <bsloftis AT yahoo.com>, 2003-10-02
The BeOS Media Kit and MIDI Kit were developed as part of the BeOS API by Be, inc.
Currently the Media Kit is only available on BeOS and derivatives (OpenBeOS). It is probably not practical to directly port it to another platform
The Media Kit provides a mechanism to manage audio, video and control data for a multimedia app. Users of the media kit would include DAW's, softsynths, and media players.
Desktop class machines.
Same.
Anyone.
Modular synth modules, realtime softsynths. There are not many "native" Media Kit effect plugins, but there is a VST wrapper that makes VST plugins compiled on BeOS appear to be MedaNodes.
Video in and/or out. Audio in and/or out, Control in and/or out.
3.1 - 3.2 are already answered above.
The Media Kit is implemented in object-oriented C++.
The Media Kit and MIDI Kit API's are defined in several header files and you link against a precompiled module that is supplied with BeOS. There is a tremendous support library included in BeOS including threading, GUI and realtime memory allocation chores.
The Media Kit and the BeOS API combine to provide extensive threading support. Nodes can be in-process or out-of-process and both are explicitly supported.
Realtime performance is guaranteed (assuming there is enough CPU power) with functions like "FindLatencyFor()" and "LateNoticeReceived()"
BeOS (the uber-host) runs a realtime audio thread which you can register a callback. Or a host app may implement their own realtime thread and send buffers to the audio thread.
Time is represented in 3 ways: Media Time (microseconds relative to the start of a particular media file), Real Time (microseconds since the computer was booted), and Performance Time (basically defines the relationship between the other two, i.e. a "time code source").
Interleaving is supported
Arbitrary data types are supported.
All media streams are raw buffers (BBuffer) with an indentifying structure (BMediaFormat) or header.
Connections between Media nodes is a multi-step process in which the nodes "negotiate" a connection format.
I believe all processing is done in-place.
There is no automatic silence handling that I know of.
see BParameter, BParameterGroup, BParameterWeb, and BControllable. Parameters can have multiple inputs and outputs, be discrete or continuous, and have multiple channels of data. Parameters can be assigned a "Unit" string (i.e Hz, dB, etc)
Handled by the host.
Parameter values are generally B_INT32_TYPE or B_FLOAT_TYPE but can be any other BeOS-defined type
The Media Kit has no persistence features. BeOS defines a BArchivable class which could be used for this purpose.
Fantastic thread support. Discussed above.
Each BControllable object can call "StartControlPanel" which generates a generic GUI window based on it's BParameters, their types and their units. A custom GUI can be written to manipulate the BParameters more elegantly.
All MIDI support is defined in the MIDI Kit. Functions like "NoteOn()" are defined to make MIDI implementations easy. MIDI functionality, controls and connections are separate from the Media Kit. The plugin must make MIDI nodes available in addition to (or instead of) Parameters.
This is a weakness of the Media Kit... it should have enveloped the MIDI kit.
Media Nodes are stored as .so modules in the system.
Media Nodes can be found and enumerated by the host via calls to BMediaRoster.
The Media Kit provides no explicit support for copy protection.
The Media Kit provides no explicit support for localization. I believe the necessary changes would need to be made in only one place, BParameter.
Things like sample rate and format can be changed basically at will. For example, the BMediaNode subclass BSoundPlayer is provied the format and samplerate as a parameter in the BufferProc callback.
The Media Kit is closed source and no longer in development. OpenBeOS is an open-source implementation of BeOS and it will include a binary-compatible Media Kit if and when it is completed.