This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
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
When building with --use-external-libs on Fedora, Ardour would fail at
runtime with messages like:
symbol lookup error: .../vamp/libardourvampplugins.so: undefined symbol: kiss_fftr_alloc
Try to automate handling of this error situation.
Fedora packaging worked around it with a custom patch that we rather
would avoid:
https://src.fedoraproject.org/rpms/ardour6/blob/rawhide/f/ardour6-missing-kissfft.patch .
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.
If queue_draw is "frozen", we simply accumulate drawing
requests in a (union) rectangle, and when finally "thawed"
the canvas submits a single redraw request for the entire
accumulated rect.
Although in theory this is all that GTK/GDK does for
draw requests, callgrind reveals significant costs
associated with the actual calltree for GtkWidget::queue_draw_area().
One potential cost is that GDK also maintains a list of
invalidated rectangles in addition to the union, and
for MIDI regions with thousands of notes, this can represent
real overhead. This approach dispenses with the rect list,
since our Canvas drawing model only uses the union rectangle
anyway.
Code within the method was using @param start_time rather than start, which is a modified
value required to generate the correct results.
This comment also contains some logical reordering, optimization and commenting
on this rather complex method.
