Found via `codespell -q 3 -S *.po,./share/patchfiles,./libs -L ba,buss,busses,doubleclick,hsi,ontop,ro,seh,siz,sord,sur,te,trough,ue`
Follow-up to 364f2f078
This allows two reader threads to proceed without blocking each other, as can
happen when the butler renders a MIDI track into an RT-safe buffer while the
GUI reads the same MidiModel/Source for visual display.
This also requires a change in the type of reference held by
a MidiAutomationListBinder.
Both the MidiSource and MidiModel have a reference to each other, and it is
important that we avoid circular references to avoid problems with object
destruction. We had been accomplishing this by having the Model hold a
weak_ptr<MidiSource>. However, the lifetime of a MidiSource and its MidiModel
are coincident and there's really no need to use a smart ptr at all. A normal
reference is just fine. However, due to constructors that accept a serialized
state, we cannot use an actual reference (we cannot set the constructor in the
initializer list), so we use a bare ptr instead.
This forces a similar change in MidiAutomationListBinder, which also maintains
a reference to the Source. However, the only purpose of this object is to
ensure that if the Source is destroyed, relevant commands will be removed from
the undo/redo history, and so all that matters here is that the binder connects
to the Destroyed signal of the source, and arranges for its own destruction
when received.
Note that the previous construction of the binder, actually holding a
shared_ptr<MidiSource> would appear have prevented the Destroyed signal from
ever being emitted (from ~Destructible), and so this may also be a bug fix that
allows MidiSources to actually be deleted (the memory object, not the file).
This also requires a change in the type of reference held by
a MidiAutomationListBinder.
Both the MidiSource and MidiModel have a reference to each other, and it is
important that we avoid circular references to avoid problems with object
destruction. We had been accomplishing this by having the Model hold a
weak_ptr<MidiSource>. However, the lifetime of a MidiSource and its MidiModel
are coincident and there's really no need to use a smart ptr at all. A normal
reference is just fine. However, due to constructors that accept a serialized
state, we cannot use an actual reference (we cannot set the constructor in the
initializer list), so we use a bare ptr instead.
This forces a similar change in MidiAutomationListBinder, which also maintains
a reference to the Source. However, the only purpose of this object is to
ensure that if the Source is destroyed, relevant commands will be removed from
the undo/redo history, and so all that matters here is that the binder connects
to the Destroyed signal of the source, and arranges for its own destruction
when received.
Note that the previous construction of the binder, actually holding a
shared_ptr<MidiSource> would appear have prevented the Destroyed signal from
ever being emitted (from ~Destructible), and so this may also be a bug fix that
allows MidiSources to actually be deleted (the memory object, not the file).
This note-mode had no effect on anything at all, at least as far back
as 5.12. There is a note-mode in the GUI which affects the duration of notes
added using the GUI, and that remains in place. It is not clear
if the _percussive member of Evoral::Sequence ever had any effect on
the actual MIDI event stream the Sequence could generate.
::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.
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.
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.
We do not want a value as large as the previous one, which limits the time
range that can be represented in 62 bits unnecessarily. The new value is
9 times smaller than the previous value, and loses only 384000 as a significant
factor.
This commit also switches to using an (inline) accessor for superclock_ticks_per_second,
making it possible in debug/testing phases to spot early/illegal uses of the value.
This does the internal shutdown of a Trigger that is shared between
a normal shutdown and when stopping for a locate/stop. There's no
output to buffers possible.
This method/design may need to change if/when we add declicking for
various conditions