Fix compilation error seen with gcc 12.0.1 on Fedora 36:
In file included from ../libs/ardour/ardour/variant.h:30,
from ../libs/ardour/ardour/parameter_descriptor.h:25,
from ../libs/ardour/ardour/automation_control.h:39,
from ../libs/ardour/ardour/amp.h:30,
from ../libs/ardour/session.cc:61:
../libs/pbd/pbd/compose.h: In instantiation of ‘StringPrivate::Composition& StringPrivate::Composition::arg(const T&) [with T = ARDOUR::PresentationInfo]’:
../libs/pbd/pbd/compose.h:277:31: required from ‘std::string string_compose(const std::string&, const T1&, const T2&, const T3&, const T4&) [with T1 = std::__cxx11::basic_string<char>; T2 = unsigned int; T3 = std::__cxx11::basic_string<char>; T4 = ARDOUR::PresentationInfo; std::string = std::__cxx11::basic_string<char>]’
../libs/ardour/session.cc:3268:4: required from here
../libs/pbd/pbd/compose.h:122:20: error: no match for ‘operator<<’ (operand types are ‘std::ostringstream’ {aka ‘std::__cxx11::basic_ostringstream<char>’} and ‘const ARDOUR::PresentationInfo’)
122 | os << obj;
| ~~~^~~~~~
This might also fix a similar problem with clang, and
5bbfac2380 can be backed out.
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).
