55 lines
2.3 KiB
Plaintext
55 lines
2.3 KiB
Plaintext
|
/*!
|
||
|
|
\class BMidiConsumer MidiConsumer.h
|
||
|
|
\brief Receives MIDI events from a producer
|
||
|
|
|
||
|
|
A consumer is an object that knows how to deal with incoming MIDI events. A
|
||
|
|
consumer can be connected to multiple producers at the same time. There is no
|
||
|
|
way to find out which producers are connected to this consumer just by looking
|
||
|
|
at the BMidiConsumer object; you will have to consult BMidiRoster for that.
|
||
|
|
|
||
|
|
A BMidiConsumer either represents a local consumer, i.e. a class extending from
|
||
|
|
BMidiLocalConsumer, or is a proxy for a remote object published by another app.
|
||
|
|
|
||
|
|
*/
|
||
|
|
|
||
|
|
/*!
|
||
|
|
\fn bigtime_t BMidiConsumer::Latency() const
|
||
|
|
\brief Returns the latency of this consumer
|
||
|
|
|
||
|
|
The latency is measured in microseconds. Producers should attempt to get MIDI
|
||
|
|
events to this consumer by <I>(when - latency)</I>. You do this by subtracting
|
||
|
|
the latency from the performance time when you spray the events (provided that
|
||
|
|
you spray these events ahead of time, of course).
|
||
|
|
|
||
|
|
You cannot <I>set</I> the latency on a BMidiConsumer, only on a
|
||
|
|
BMidiLocalConsumer.
|
||
|
|
|
||
|
|
The latency issue gets slightly more complicated when multiple endpoints are
|
||
|
|
chained together, as in the following picture:
|
||
|
|
|
||
|
|
\verbatim
|
||
|
|
+-------+ +-------------+ +-------+
|
||
|
|
| | | | | |
|
||
|
|
| prodA |---->| consB prodB |---->| consC |
|
||
|
|
| | | | | |
|
||
|
|
+-------+ +-------------+ +-------+
|
||
|
|
appA appB (filter) appC
|
||
|
|
\endverbatim
|
||
|
|
|
||
|
|
Suppose consC has 200ms latency, and consB has 100ms latency. If consB simply
|
||
|
|
reports 100ms, then prodA will schedule its events for (t - 100), which is
|
||
|
|
really 200ms too late. (Of course, producers send out their events as soon as
|
||
|
|
possible, so depending on the load of the system, everything may work out just
|
||
|
|
fine.)
|
||
|
|
|
||
|
|
ConsB should report the latency of the consumer that is hooked up to its
|
||
|
|
output, consC, in addition to its own latency. In other words, the full
|
||
|
|
downstream latency. So, the reported latency in this case would be 300ms. This
|
||
|
|
also means that appB should change the latency of consB when prodB makes or
|
||
|
|
breaks a connection, and when consC reports a latency change. (If multiple
|
||
|
|
consumers are connected to prodB, you should take the slowest one.)
|
||
|
|
Unfortunately, the Midi Kit provides no easy mechanism for doing any of this,
|
||
|
|
so you are on your own here.
|
||
|
|
|
||
|
|
*/
|