This ensures that the user will see a "POOL OUT OF MEMORY" message.
In rare case dumping the pool can segfault when printing the Event,
The pool is zero initialized and only ever contains events, so
in theory it is safe to print them..
When exporting many ranges, locate and restarting transport for
every ranged a SessionEvent::TransportStateChange event is queued.
Since freewheel export does not process events. Those events
can accumulate:
https://discourse.ardour.org/t/pipewire-jack-export-freeze/107383/18?u=x42
During export those requests can be safely ignored because the only
purpose is to emit a TransportStateChange() signal when the playhead
passes a given location and notify the UI.
This fixes automation lanes bleeding into the ruler area.
The bounding box of all items in the main canvas group starts
at -0.5, and the cursor-scroll-group at -1.5. This is calculated
to include line-width, and outlines outside the item(s).
A scroll-group however must not extend its render area to
render those.
The region-gain envelop is an Automation list that uses AudioTime
regardless of the regions own position.
Since the actual audio data is using always using samples this
results in reliable envelopes without the reduced granularity of
BeatTime.
All points the list have to be in the AudioTime domain.
Previously it was possible to have a mixed-domain list e.g.
- add 2h:30min long source
- lock it to music-time
- set grid and snap to 1/8 note
- range select some range shortly after 2:25
- draw region-gain for range
<events>
a0 1
a492113664000 1.0000001192092896
a492113737500 0
a494032822500 0
a494032896000 1.0000003048365
b34560000 1.0000003048365
</events>
jack1 (which is Linux only) does not have a jack_client_stop_thread
API, and expects the application to call pthread_join().
This fixes an issue when the application is compiled using jack2 headers
but the application later runs using jack1's library.
When a session-range coincides with a loop-range location, moving
the session-range also updates the loop-range.
Keeping session and loop-range in sync can be useful if the whole
session is looped. However markers are treated individually, so
we need prevent invalid ranges.
If session-start and loop-start coincide, but loop-end is before the
end-marker, it is possible to move session-start beyond the loop-end.
Automation Controls (and controls in general) are now
only updated in realtime context. Either via automation-playback,
or via SessioEvent. This directly sets the Control:_user_value
(before emitting the Changed signal).
The GUI does not need to evaluate the control at a given point
in time, so the API call can be removed and unified.
This commit first removes all calls to "get_double" to ensure
that no special cases exist.
::automation_run() evaluates the value, possibly ahead of time
depending on latency-compensation. The actual value is set in
realtime-context via set_value_unchecked() -> actually_set_value()
which emits the Changed signal.
At this point in time Control::user_value is already set correctly.
There is no need to evaluate and interpolate again, at a potentially
incorrect (uncompensated) time: `_session.transport_sample()`.
This fixes an issue with the GUI Automation control showing an
outdated value when there is an "immediate jump" in the signal:
eg. add a latent plugin post-fader, then automate the Fader to jump
from 0dB to -inf dB (snap to grid) and play though that transition.
(Plugin controls were not affected by this bug, the process
cycle is split for those, but Mixbus internal AC were affected).
When the loop-range is defined in BeatTime, the disk-reader encounters
rounding issues due to time-domain mismatches.
With a simple session fixed BPM at 120, 48kHz.
looping 1 bar exactly 2 sec at the start of the session:
```
Range::squish start: b0 end: b7680 squish: a113554560
Range::squish using modulo: b45 = a661500
Range::squish using modulo in TD: a5760
Range::squish using earlier(): a658560
```
The correct answer is a113554560 - 2 * 56448000 [SC/sec] = a658560
Calculating the modulo iteratively is not great, however usually
only one iteration is required.
PBD::Transmitter is neither thread-safe nor rt-safe. This likely
fixes a crash on macOS when process-threads are started.
Many threads simultaneously enter coreaudio_process_thread() and
log a message calling `PBD::info << .. << endmsg` simultaneously.
This expands significantly the maximum number of Beats that can be represented, which is a good
thing in itself. It slightly speeds up some Beats::operator methods, and slightly slows down
::get_beats() and ::get_ticks().
One minor change in an API user was required, and several tweaks to the unit tests due to the
macros being used by cppunit creating possible type confusion.
Units test pass
Consistently use Tertiary for Group Override on all platforms (and be consistent about it)
Consistently use Primary-mod for Momentary on all platforms (partially reverts 47932f)
Primary modifier is used for fine-adjust on knobs and sliders, with no analogous operation on switches.
The pre-nutemo code used fmod() to calculate the offset into the bar:
`bar_fract = fmod (barbeat, 1.0); // fraction of bar elapsed`
with nutempo, beats start at 1, and the tick offset must also be
taken into account.
The bug was introduced in f67029bd0
PortIndex is sorted by name, and uses port-name as unique identifier.
Ports can be re-named concurrently with processing.
::set_port_name() updates the RCU in the background. The engine
may concurrently process with an old RCU reader value.
In this case valid_port() failed in the process-callback.
and ::get_buffer() returned NULL
is_button2_event() was used to detect the user's desire for a
momentary-click on some buttons (mute, solo, mixer scenes)
is_momentary_push_event() disambiguates this action from is_button2_event()
for the special case of momentary, we can drop the workarounds for
the lack of middle-mouse buttons on Mac, and instead just use
shift+left-click on all platforms.
When TempoMap::copy_points() is called, the new points are intended to belong
to the (nascent) new map. But the copy constructor for the points leaves the
_map member of a Point unchanged, and so the new points reference the old
map (forever!). ::copy_points() must reset each Point to reference the new map.
Refactored the object that has the _map member, so that we could limit access
to its ::set_map() method to TempoMap.
Note that ::find_all_sources_across_snapshots() finds and retains
all sources in the SourceList of other snapshots regardless
if they are used in those snapshots.
A route may be processed before latency-compensation callback
sets the route's output_latency. In this case a random offset
was added to the start/end position (via latency_offset).
if a slot becomes active, and the transport is not rolling, it still
asks the transport to roll. however, (1) there's only 1 request across
all triggerboxen (2) the request will not be handled till the next
process cycle (3) the triggerbox returns after the request i.e. it
waits until the transport is rolling
This is otherwise only caught later in the rt-thread after
scheduling a RealTimeOperation via AutomationControl::check_rt.
There is no need to schedule cross-thread events when the
value is not about to be changed.
This can greatly reduce the number of signals emitted by
restoring a slot, which improves performance and also prevents
the EventPool from filling up with useless events.
It can happen that the EventQueue fills up with
SessionEvent::RealTimeOperation. Those are to scheduled to be
free()ed later the GUI thread via event_loop->call_slot().
However it can happen that the GUI EventPool is full, so the request
to call Session::rt_cleanup, is never executed.
In this case the SessionEvent pool can fill up with RealTime
Operations which remain there permanently.
It can happen that ::get_request() returns NULL if the
EventPool is full. In that case the slot is never called.
In this case the caller can now take action.
Plugins on Apple can be multi-arch (Intel + ARM), or AUs may
be bridged by Rosetta.
A user can also run Intel binary of Ardour or M1 binary on
M1 CPUs on macOS. Each can see different plugins - notably
VST3 plugins that are Intel only can be scanned using the
Intel binary, but are later not available with the M1 build.
There is no longer an extra set of rt-threads, but existing
process-graph threads are reused.
There are two main benefits to this approach: graph-threads
have a SessioEvent pool and ProcessThread buffers. They are
also joined to work-groups (on macOS), or JACK created threads
(cgroups).
The process-graph trigger_queue only needs to call
::prep() and ::run() without knowing any further details.
This is in preparation for using the graph-threads for rt-tasks
Route::silence() runs plugins. With a heavy session
that relies on multi-core processing, sending silence
to processors will have to be done in parallel.
Otherwise it can result in large DSP load and xruns.
This may allow to revert b3497b3f8f, which was
a prior attempt to resolve this, before understanding
the actual cause.
When auditioning, ardour's process_audition calls Route::silence
for all routes. PluginInsert::silence simply fed all [ports of all
[replicated] plugins with silence, regardless of port-mapping.
This can cause some VST2/3 plugins to change state, and enable ports
(e.g. stereo VST2 plugins on mono tracks), causing glitches.
This commit is mainly intended to investigate how significant
this glitch is when starting to audition.
* don't create a new MixerScene if one already exists
* only resize the vector when necessary
* adding a new scene at position N should not shrink the vector size
Previously it was possible to cause a 64bit signed to 32bit
unsigned overflow. `from_stretcher` is pframes_t aka. uint32_t.
With int64_t arguments a std::min() expression producing negative
result will result in large 32bit values:
(pframes_t) std::min<int64_t>(1024, 176400 - 187392) = 4294956304
This produced a segfault when used as n_samples to copy in
buf.accumulate_from()
Because a bartime point IS-A tempo point and IS-A meter point, we cannot just delete the tempo
point passed into core_add_tempo() if the new point replaces an existing one. Ditto for meter.
So, leave that logic up to the caller
timecnt_t and timepos_t constructors with the initial argument as an int64_t
are assumed to be using samples. We need to use the explicit factory methods
instead.
Session handles the case when the button is used to enable cue triggering, by
forcing a locate to the current transport position.
TriggerBox now connects to the correct configuration object to notice when cue
triggering is disabled, and sets _cancel_locate_armed appropriately.
No behavior should be changed by this modification; the argument has a default value of false, which
matches previous semantics, and every instance where the argument is specified, it is given as false.
This uses boost::multiprecision::int512_t when multiplying and dividing by the numerator
and denominator of a ratio_t. 128 bits would be sufficient but for some reason, the boost
docs show the 512 bit variant being very slightly faster.
This is a better solution than using a double, which although it will prevent overflow
has fairly limited resolution.
Region fades would sometimes get in a mode with weird behaviour. They
would be drawn in 2d with crossing lines, mainly moving back and forth
horizontally - not as a function of time. It would sound as it looked.
The fade would sometimes jump around when resizing. It could be worked
around by resetting the fade shape. It turned out the problem could be
reproduced by making minute long fades.
This change fixes or works around the problem.
Back story:
timepos_t (in temporal/timeline.h) uses 62 bit for integer value and the
max value is thus 4611686018427387904 ~ 5e18. timepos_t counts
superclocks, where superclock_ticks_per_second is 56448000 ~ 6e7. It can
thus store up to 8e10 seconds - thousands of years.
ratio_t (in temporal/types.h) can represent fractions as 64 bit (signed)
numerator and denominator. timepos_t avoids floating point operations,
but has operator* with ratio_t. To avoid crazy loss of precision it will
multiply the superclock count with the numerator before dividing with
the denominator.
Audio region fade in and out uses a number of increasing timepos_t
values (in a ControlList) up to the length of fade. When dragging to
resize, these values are (in_x_scale) multiplied with the ratio_t of the
new and old fade length. The problem is that the 62 bits will overflow
if using fades more than sqrt(5e18) ~ 2e9 superclock ticks ~ 38 seconds.
It will overflow into the "beat" flag and (at 58 seconds) into the sign
bit. The timepos_t values in the fade will thus jump and can be negative
or change to count beats.
To work around that problem, this changeset just use floating point
values for scaling the timepos_t values. All scaled values are stored as
integer anyway, so it should not make any actual difference for this use
case. There might however be other uses of ControlList where it matters.
As an implementation detail of this "workaround" of using double, it
could perhaps also be nice to implement timepos_t operator* (or
operator*=) for double. But I'm not sure we want floating point support
in timepos_t.
An alternative (and better) solution would be to convince the fraction
multiplication to use 128 bits. It is essential to avoid overflow -
mainly in static analysis, alternatively as runtime checks or asserts.
This also allows to disable the resampler, effectively disabling
varispeed support, for the benefit of adding no additional latency.
By default 2 * 16 samples latency are added, due to port-resampler,
this is not desirable if Ardour is used as mixer only.
Session::route_processors_changed accumulates signals emitted
in realtime and processing is delegated to a dedicated rt-safe
thread. Previously this resulted in any changed to be converted
to a `GeneralChange`, which unconditionally triggered a route-reorder.
Record-arming a track causes a MeterPointChange (meters change to "in"),
and this caused routes to be resorted and a latency-update.
While the former is reasonable (Ardour prefers to process
rec-armed routes first), the latter certainly is not.
Even if we start at time T, if the tempo point before T is ramped, we need to
adjust it's omega value based on the beat time of the following tempo point. If
we don't do this, then using that tempo to compute ::superclock_at() for
subsequent points will be incorrect.
Note: there may be an ordering issue here with Tempo/Meter points. We might
need to pass over all tempo points first, then process meters etc. Something
like that.
libs/ardour/session_state.cc:1500:13: note: in instantiation of
function template specialization 'XMLNode::set_property<unsigned long>'
requested here
libs/pbd/pbd/string_convert.h:151:11: error:
type 'unsigned long' cannot be used prior to '::' because it
has no members
The master needs to be restored first, otherwise setting
the master value with be propagated. Furthermore the
actual value is saved at the time of VCA assignment.
Restoring the vaule needs to scale by the master-reduced value.
changes in tempo can be negative (decelerando/slowing down), and thus so can _omega. We cannot call log() or its
cousins on negative values, so in this scenario use an alternate expression for "t from b" in the tempo.pdf paper
We discovered in the past that the C++ API for GSource/Glib::Source has some fatal and unfixable flaws. Copy similar
code and just use the C API for GSource instead
This is based on code from earlier commits that were later reversed, but we need some mechanism
to ensure that threads have a thread local tempo map ptr set. The big difference is that this
time we do not implement this for all instances of an AbstractUI - implementation is left to
each thread/event loop
Events in the delay-buffer must be shifted back every cycle.
Also in case of fixed-delay-lines events may not be in sequence
since events are only sorted at backend port-level.
this solves the oft-recurring problem where we assign
a beat-count of '3' or '7' because minipm mis-detected the tempo,
and that situation is vanishingly rare. it's better to assume 4 or 8
the user always has the option to change the number of beats (and
therefore the detected tempo) manually, for those clips that are
in a different time signature. but minibpm cannot be expected
to help us there.
NOTE: this is a fallback to make things 'just work' lacking any other context.
* if the tempo is detected in the filename, we use that instead
* clips that were recorded to the timeline use that bpm+timesig
* in the future we can use file-metadata (acidized wave?) instead
* this is audio-only: midi files can have an embedded timesignature
but... given no other information, experience says the vast majority
of downloaded/purchased clips will be 1,2 or 4 bars at 4/4.
