|
OSSIA
Open Scenario System for Interactive Application
|
Inherited by ossia::net::midi::midi_protocol.
What the dataflow graph needs of a protocol before it can give one of its nodes a MIDI port: somewhere to put what arrives, somewhere to send what leaves, and the clock the two are timed against.
Separate from midi_protocol because a protocol can build a tree of its own and still carry MIDI – a device description's controls are parameters, but the port they are read from is the same wire.
Public Member Functions | |
| bool | receive_ump (const libremidi::ump &m) noexcept |
| virtual libremidi::midi_in * | midi_in () const noexcept=0 |
| virtual void | enable_registration ()=0 |
| virtual void | push_value (const libremidi::ump &)=0 |
| Send, for a MIDI port written to. | |
| virtual void | push_value (const libremidi::message &)=0 |
| Likewise, for what is authored as MIDI 1 bytes. | |
| virtual std::optional< int > | stream_channel (const node_base &n) const noexcept |
Public Attributes | |
| ossia::spsc_queue< libremidi::ump > | messages {queue_capacity} |
Static Public Attributes | |
| static constexpr std::size_t | queue_capacity = 2048 |
| A tick's worth of messages many times over, and a ceiling all the same. | |
|
inlinenoexcept |
Hold m for the next tick, or drop it if nothing is draining.
A protocol keeps streaming for as long as it is open, and a graph that stopped reading – execution ended, the process was deleted – would otherwise make it allocate on every message for as long as the device stays plugged in.
|
pure virtualnoexcept |
The port messages are timed against, or nullptr when nothing is open for input. A message's place in a tick is its timestamp measured from this.
|
pure virtual |
Start filling messages. A protocol nothing reads as a stream should not pay to keep one.
|
virtualnoexcept |
The channel n stands for, so that a port bound to it hears that channel and not the other fifteen. std::nullopt for a node standing for the whole stream, which is what the root of a device is.
| ossia::spsc_queue<libremidi::ump> ossia::net::midi::midi_stream::messages {queue_capacity} |
What arrived since the last tick: filled by the protocol's input callback, drained by execution_state::get_new_values().
Single producer, single consumer: the backend's callback thread and the execution thread.
Written through receive_ump, never enqueued directly: the queue grows by allocating, and the callback thread is the one feeding the audio graph.