No Matches
Public Member Functions | List of all members
BMidiConsumer Class Reference

Receives MIDI events from a producer. More...

#include <MidiConsumer.h>

Inherits BMidiEndpoint.

Inherited by BMidiLocalConsumer.

Public Member Functions

bigtime_t Latency () const
 Returns the latency of this consumer.
- Public Member Functions inherited from BMidiEndpoint
status_t Acquire ()
 Increments the endpoint's reference count.
status_t GetProperties (BMessage *properties) const
 Reads the properties of the endpoint.
int32 ID () const
 Returns the ID of the endpoint.
bool IsConsumer () const
 Determines whether this endpoint is a BMidiConsumer.
bool IsLocal () const
 Determines whether this endpoint represents a local object.
bool IsPersistent () const
 Not used.
bool IsProducer () const
 Determines whether this endpoint is a BMidiProducer.
bool IsRemote () const
 Determines whether this endpoint is a proxy for a remote object.
bool IsValid () const
 Determines whether the endpoint still exists.
const char * Name () const
 Returns the name of the endpoint.
status_t Register ()
 Publishes the endpoint on the roster.
status_t Release ()
 Decrements the endpoint's reference count.
void SetName (const char *name)
 Changes the name of the endpoint.
status_t SetProperties (const BMessage *properties)
 Changes the properties of the endpoint.
status_t Unregister ()
 Hides the endpoint from the roster/.

Detailed Description

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.

Member Function Documentation

◆ Latency()

bigtime_t BMidiConsumer::Latency ( ) const

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).

You cannot set 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:

+-------+     +-------------+     +-------+
|       |     |             |     |       |
| 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.