Also speeds up PT imports during region creation.
This is because regions are imported immediately when sources
are grouped into multichannels rather than doing it in another pass
This allows bulk creating tracks with different name templates.
Simply call the bulk method multiple times as required and finally
call add_routes() once.
Although setting CURLOPT_PROGRESSDATA appears to work to set the pointer
passed into the new CURL_XFERINFOFUNCTION option, the documented option is
now CURLOPT_XFERINFODATA.
We must not walk past a MusicTimePoint if the reftime is a BBT_Argument.
May try to fold this back into the fully-templated version in a subsequent commit.
Clamp misaligned prefix loops to the remaining frame count to avoid
nframes underflow and potential out-of-bounds access for small buffers.
Apply vabsq_f32() to all SIMD loads before peak reduction to ensure
correct absolute peak calculation in unrolled NEON paths.
This fails when done via direct import into a cue slot which assumes that all sources created
must be associated with the region, and that each source must have a model.
This change drops the metadata-only track/source from being returned by Session::import_files()
Note that in order to avoid refcnt'ing from prolonging the life of the source we want to drop,
we do not announce the sources when they are created, but defer that until we know they are
going to be used post-import
It is risky to take the sample value returned by this method and then convert it back
to either superclocks or beats, mostly because tempo & meter times are generally in
music time, and converting from superclocks to samples loses precision.
This rename is there to serve as a reminder to developers to be careful when using
this method
MixerStrip::show_send() may unset _panner if the send
has no panner. When then triggering an action that emits
`Pannable::automation_state_changed` (like un/link send panners)
of the main panner, Ardour crashed.
Note that PannerUI::set_panner already handed that case.
Despite comments already in the code, the logic used to remove a
{Tempo,Meter,BarTime} point from the _points list was incorrect. While it is
true that we can use a duple of (type,time) to find a given point,
::remove_point() was not doing that and instead assumed just the time value
could be used.
This meant that if you placed a tempo and meter at the same point in time, then
changed one of them, ::remove_point() could remove the wrong point from the
_points list.
In #10063 this manifests as the wrong grid being drawn after a tempo point
edit.
This commit alters the ::core_remove_xxx() methods to return a pointer to the
actual Point object that was removed from {_tempos,_meters,_bartimes} and then
we pass that to ::remove_point() for lookup and removal by address.
It also "fixes" a couple of instances of ::core_remove_xxx() without any
removal from the _points list (since ::core_remove_tempo() and
::core_remove_meter() do not do this; ::core_remove_bartime() does,
however). It is not immediately obvious what bad behavior would arise from the
existing code in these cases, but it seems clearly incorrect that the _points
list would contain points no longer present in _tempos or _meters.
when these points have times set in beat time (which they nearly always do), converting
their superclock time to samples and back loses accuracy. this caused the TempoMap to
find the wrong earlier points in the map.
It is still up for consideration that the editing code ought to identify explicitly
that we're working on an existing point, or adding a new one, and avoid lookup
by time for the existing points
