Triggerboxen were being executed during the latency preroll phase, which is
inappropriate. ::fast_forward() will prepare them to run at precisely the
correct time. So we add an explicit clause to avoid this.
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L ba,buss,busses,discreet,doubleclick,hsi,ontop,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
Rather than start at zero, we now search backwards for the first relevant cue
before the locate position, making our task in ffwd'ing from there much simpler
since there are no other cues to consider
Also remove Meter:: versions of related methods, because they are not necessary. We
only need metrical information for operations like ::round_to_bar()
* there are rare cases where a midi clip would not advance the ffwd position, looping endlessly
* this problem did not occur when the user chose an explicit Follow Length (different code path)
This workaround bypasses RegionMap and SessionPlaylist APIs
(region_use_count, destroy_region) which are not directly
applicable to Triggerboxes. There are likely various edge
cases until TriggerBoxes integrate with Session Playlist.
e.g. whole file regions generated for regions/source used by
triggerboxes are cleaned up.
A compound region itself may be unused, but the nested source
it provides can be used in another region compound.
In this case the first, unused, region needs to be saved
to save the nested source.
Constructing a playlist from another playlist plus an offset used the wrong
RegionFactory::create method. By failing to pass in the offset to the region
constructor, the newly created region gets its envelope (and possibly other
automation data) from the start of the existing region, not its own start.
There was a logic error previously which failed to consider follow actions (and follow count).
Now we find a relevant cue, and use follow actions and follow counts as we move forward
in time
This fixes an issue with LV2 plugin that unconditionally
initialize LV2 Atom ports even if they are not connected.
eg. JUCE7 produces LV2s at the time of writing.
The actual goal here is to use direct InterpolationStyle serialization
in MidiSource (identical to AutomationList). enum_2_string()
does not work for Evoral types.
As side-effect virtual base-classes have been changed to pass
Parameters as const references
This fixes an issue when creating tracks or busses with a colon
in the name. Renaming those tracks later IO::set_name()
crashed in current_name.replace(std::string::npos,..).
`IO::build_legal_port_name` uses ";" instead of ":" while
`IO::set_name` replaced it with a "-".
Initially the IO name included the colon, so ports created
use a semicolon. But after renaming the IO, ::set_name() applies
the replacement and the IO's name is changed to include the "-".
This leads to a conflict with ports that already have the semicolon
in the port-name.
Loop Location start="a1665678660" end="b145920"
Loop-end (at 122BPM) is a2109859636
at 48kHz this is sample 1794098.32
Now play the loop and play sample 1794098 = a2109859248
Range::squish start: a1665678660 end: a2109859636 squish: a2109859248
squish() does nothing, since there are still 388 superclock-ticks
until the end of the loop.
However, DiskReader::get_midi_playback convertes the value back
to samples(), this leads to effective_start == loop_end;
resulting in an endless loop.
Thanks to MikeLupe to provide a session to reproduce this issue.
So far group-override "inverts" group behavior. Disabled groups
(or group settings) are enabled and vice-versa.
When the setting is disabled, groups can only ever be disabled
(Controllable::NoGroup) and group-override will not enable them
(Controllable::InverseGroup).