When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
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
Let the plugin implementation of Plugin::add_state use a LocaleGuard if it is
necessary (VST/LV2). This puts the LocaleGuards where they are required but the
LocaleGuards in Session::set/get_state will mean these LocaleGuards are a noop.
They are still useful for documentation purposes and in case the code is called
from a non-Session context at some point.
VST used the count of available of presets as URI:
- add 2 presets (1,2)
- remove first, add another one -> two presets with same URI (2,2)
PluginInfo::get_presets() simply lists all (name only) in a vector.
Plugin::find_presets() uses the URI in a map (unique by URI).
..various ensuing bugs: eg. Plugin::remove_preset() looked up by name,
but didn't check for NULL.
The latter is only really relevant for Audio Units.
This fixes an issue with vocoders or audio-plugins that simply have
a MIDI input for other purposes to be wrongly categorized as Instruments..
.. and thereby override strict-i/o rules (prefer stereo)
Pass current (latency compensated) cycle times to plugin.
This fixes time-reporting to plugins and also fixes automation
and when bouncing (the session->transport* is not valid) etc.
well, now...
- Midi-Ports have a midi-buffer.
- Midi-Tracks have a midi-buffer.
- Midi-tracks have a diskstream.
- Midi-diskstream has a midi-ring-buffer.
- Midi-tracks have a delivery
- The delivery can get a reference to the actual backend-ports
- The delivery calls the Midi-Port's flush() buffer to send out queued events
at the end of a cycle
all clear ? :)
- when splitting the process-cycle: only the Ports are informed.
all other objects see a "normal" short process cycle starting at "0".
The offset needs to be applied early on, so that internally routed buffers
push the event at the correct time when combining the buffer with
immediate and async events.
Luckily Port::port_offset() is a static member, available to all, objects,
which allows to bridge the conceptual gap between the diskstream and
the delivery.
There's a snag:
When there's a note-on directly at the beginning of the loop it coincides
with the panic message sent when looping.
The panic comes before note events, so it *should* be good.
Also the final note-offs (state tracker end of loop/region) are sent
1 sample too early (smells like an off-by-one), and are hence dropped.
(no matter we send a panic right after it).
It should really be at the same time, just before the panic.
The signal exists to notify listeners that something outside of the host's control (e.g. a plugin's own GUI for AU or VST)
has modified a plugin parameter. Previous code had strange feedback loops and ambiguous semantics.
