Receives MIDI events from a producer. More...
Inherited by BMidiLocalConsumer.
|bigtime_t||Latency () const|
|Returns the latency of this consumer. More...|
|Public Member Functions inherited from BMidiEndpoint|
|Increments the endpoint's reference count. More...|
|status_t||GetProperties (BMessage *properties) const|
|Reads the properties of the endpoint. More...|
|int32||ID () const|
|Returns the ID of the endpoint. More...|
|bool||IsConsumer () const|
|Determines whether this endpoint is a BMidiConsumer. More...|
|bool||IsLocal () const|
|Determines whether this endpoint represents a local object. More...|
|bool||IsPersistent () const|
|Not used. More...|
|bool||IsProducer () const|
|Determines whether this endpoint is a BMidiProducer. More...|
|bool||IsRemote () const|
|Determines whether this endpoint is a proxy for a remote object. More...|
|bool||IsValid () const|
|Determines whether the endpoint still exists. More...|
|const char *||Name () const|
|Returns the name of the endpoint. More...|
|Publishes the endpoint on the roster. More...|
|Decrements the endpoint's reference count. More...|
|void||SetName (const char *name)|
|Changes the name of the endpoint. More...|
|status_t||SetProperties (const BMessage *properties)|
|Changes the properties of the endpoint. More...|
|Hides the endpoint from the roster/. More...|
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.
Returns the latency of this consumer.
The latency is measured in microseconds. Producers should attempt to get MIDI events to this consumer by (when - latency). 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).
The latency issue gets slightly more complicated when multiple endpoints are chained together, as in the following picture:
+-------+ +-------------+ +-------+ | | | | | | | prodA |---->| consB prodB |---->| consC | | | | | | | +-------+ +-------------+ +-------+ appA appB (filter) appC
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.