this really tries to do the right thing regarding meta-events we're interested in,
and channel events we're interested in, no matter how they are distributed across
different channels in the SMF.
it augments/extends the work started in 8a554f659c
The RouteGroup containing the deleted routes emits the RouteRemoved signal; Session handles this
and if the RouteGroup is now empty, deletes the RouteGroup *while in the middle of the signal
emission process*. This deletes the Signal (since it was owned by the RouteGroup) which leads
to a crash inside the signal emission code, since that is now running "on" a deleted Signal
object.
This change simply makes that signal static, and so deleting the RouteGroup has no effect
on the Signal itself.
More changes to come related to better (shared_ptr<RouteGroup>) mgmt of RouteGroup lifetimes.
```
== Info: WARNING: disabling hostname validation also disables SNI.
```
which leads to a "431 Misdirected Request" reply for servers
with shared hosting.
This handles the case where only part of a bus' ports are
connected. This can happen when a given speaker configuration
is not directly accepted, and the plugin provides more I/O than
requested.
This fixes some plugins that require a valid Bus/SpeakerArrangement
setting to set the available per bus I/O channel-count.
(e.g. Altiverb). Most other VST3s initially announce all
available channels.
TODO: check that this does not break plugins with optional
busses (sidechain in, multi-out instruments)
* Add iCON Pro Audio P1-NANO device with option of P1-X extenders left or right
* Resolve Metering on P1-M/X and P1-NANO
* Resolve SMPTE/beats display on P1-M/X and P1-NANO
This now follows MIDITrigger - when a region's bounds are changed, we reload
the data corresponding to the region into memory, queue up a PendingSwap and
then have Trigger::check_edit_swap() switch to the new data when
necessary (synchronously with ::run).
This comment also removes AudioTrigger::_start_offset because there is never
any start offet - the data in memory is always precisely the data corresponding
to the region. If the region bounds are modified, we reload the correct data
into memory. This also applies to the recently added _user_data_length - again,
the data in memory always corresponds to the full span of the region/clip being
used in process context.
This differs a little from MIDITrigger, where we do in fact load the entire
source and maintain trigger-only bounds. That's because the amount of data for
MIDI is generally small, and so it makes more sense to just put it all in
memory and adjust which parts of it we use. For audio, the region could be
minutes (or hours!) into an audio source, and there's no point having all that
data in memory when we do not need it.
These changes now make editing clip boundaries in AudioClipEditor generally
functional, though some polishing is still in the works.
This API was imagined as useful when Triggerbox started, but we never use
them and likely never will. If some part of them is required in the future, it
will likely be in a different form.
