Age | Commit message (Collapse) | Author |
|
This type of MIDI port fetches all of its data from inside ::cycle_start(),
and delivers it to a FIFO connected to another thread (typically a
control surface).
Unlike regular MidiPorts, which will be read from inside a Session::process()
call, these ports will read their data once per AudioEngine::process() cycle.
They therefore cannot use MidiPort::get_midi_buffer() which scales and adjusts
event timestamps as if the data is being accessed from within Session::process().
It is still an open question whether or not AsyncMIDIPort::cycle_start() should
still scale event timestamps by speed. In some respects it seems more appropriate
to do so, and the reading thread (e.g. a control surface) doesn't care about
the "nframes" limit on timestamps that exists for calls within a Session::process()
tree. For now, leave the timestamps unscaled by speed.
|
|
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
I'm not sure if this is really the best way to do event types (should it
just be a completely static enum in evoral, or completely dynamic and
provided by the type map, or a mix like currently?), but previously the
event type was frequently set to either total garbage, or parameter
types, which are a different thing.
This fixes all those cases, and makes Evoral::EventType an enum so the
compiler will warn about implicit conversions from int.
|
|
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
|
|
This allows to flush an async MIDI port's ringbuffer at cycle-start,
to makes its data available as "input/source" during process(), while
collecting data in the background for the next cycle.
This facilitates virtual MIDI Ports for eg. Control Surface Pads:
output from a surface, input to Ardour channels.
|
|
|
|
|
|
Not tracked if parent/owner port changes latency
|
|
anything.
|
|
|
|
Filter functor needs to be set before registering port, so provide it when adding the port.
|
|
The shadow port is a secondary port that can be used to allow others to get a copy of part, all or none of the MIDI
stream received by the owner (input) port.
|
|
|
|
Increased the size of the FIFO that acts as the intermediate between writers and the MidiBuffer. Changed
implementation of ::write() to notice if MidiBuffer::push_back() fails, and then just leave data queued
for subsequent calls to ::flush_output_fifo().
Note: the logic here will be broken by invalid events/data, which ALSO cause MidiBuffer::push_back() to
return false. That needs fixing
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
|
|
|
|
This is not used anywhere in Evoral and is just a wrapper around the PBD
RingBuffer anyway. Towards a (once again?) independently buildable/testable
Evoral and fewer cross-dependencies.
|
|
|
|
change markers
|
|
|
|
unknown (required to be buildable with MSVC)
|
|
|
|
|
|
to be complete)
|
|
callback again
|
|
|