::start_audio_export() may be called from a background thread
which does not yet have a thread-local TempoMap.
Track::seek() calls ARDOUR::AudioPlaylist::read()
which calls Playlist::regions_touched_locked() which may require
a TempoMap to calculate overage with Temporal::Beats
This fixes mp3 export on Linux/ARM (Raspberry Pi) with
system-wide dynamically linked ffmpeg. Otherwise the there
would be library conflicts with ardour-bundled libz and libcairo.
This allows regions to be correctly imported to their
actual track number now that they are numbered from zero
without any gaps by ptformat, removing the need for a lookup table.
In layered mode the scroomer is not usable with stacked MIDI regions.
Ideally we'd only hide it if there is more than one layer
but that is for another day.
Pane::set_divider() constrains the divider so that widget
minimum sizes are honored.
Initially the mixer is empty and the tab has width of ~110px
(just scroll window). Pane::on_size_allocate() calls set_divider()
before actual mixer-strips are added and before the mixer window
size was restored. This incorrectly constrained pane sizes.
This was broken during development of ripple-all.
First explicit rdiff_and_add_command() was used, but
when that was reverted later, the original stateful_diff
was not restored.
989408626d1ccf272d58
std::upper_bound() was not the correct tool to find the existing point,
it should have been std::lower_bound(). For code consistency, this
change doesn't use either but like ::remove_tempo() and similar methods,
just iterates over the whole list
bugfix: changing the FA state can overwrite the clip's name and color
Some params (like gain) can and should take effect immediately
by directly setting the properties. TRIGGER_DIRECT_SET does that.
But we still, ALSO have to set the ui_state, because when the
triggerbox imports ui_state via update_properties() it will
overwrite your changes.
Said another way: since we use a queued ui_state to set the properties,
you ALWAYS have to set and use the ui_state mechanism, even if you want
to short-circuit the process for specific properties.
Having identified the trigger that will be running at a given transport position, we determine its effective
length (not necessarily its own length) and last start, then "jump" forward to the next-earliest start
point prior to the transport position. This greatly reduces the amount of actual audio processing we
need to do to prepare the trigger to run in sync at the transport position.
This commit also adjusts the targetted transport position by the processor's playback offset, so that
it is correctly prepared to run() once the transport starts again.
Logic errors when using cue-isolated or empty triggers were also fixed.
* Inhibit prevents any FAs, FA Count, Probability, etc ... but leaves settings intact
* Removed Inhibit from the Right FA menu ... it only needs to be set on the Left
* Removed Inhibit from the clip context menu, we only want shortcuts to explicit actions there
This addresses an issue with missing guard points at the
beginning of a range drag when the range is not snapped to
a musical grid.
Note that the code below "same thing for the end" does not use
.beats() either.
We know when we call non_realtime_stop() if we will be subsequently
locating. If so, do not do an additional non_realtime_locate() from
within the stop.
* if the same color is used for the marker and the flag, some range markers looked odd
* now that rulers are highlighted when you hover, it's less necessary to disambiguate by shape
Region-gain (unlike other automation) is specific to the
region and independent of the source. Region::start() offset
does not apply. When region-start is trimmed the region's
envelope is modified (not just offset). The event-list is truncated.
Any audio-region envelope does (and must) have a point exactly
at the start and end of the region.
truncate_start() can thus calculate the earliest position of
valid events with the new length relative to the last event.
The mathematical operator for that is subtraction, not distance.
