Cairo::curve_to renders cubic Bézier splines, those are not
generally useful in a DAW context.
Canvas::Curve implements centripetal catmull-rom spline drawing
which can be used for fades and automation interpolation.
This adds a basic support to use multiple sound-cards, currently
limited to two devices: In/Out with shared settings.
Advanced setups still have to resort to using the ARDOUR_ALSA_EXT
environment variable
This apparently happens on some Windows systems when exporting
a range starting at 00:00:00:00
I'm still hoping there's a better fix for these race-condition
issues, perhaps by kicking the TFSM...
When running from the src-tree, ardev_common.sh sets multiple
data-paths, to allow running ./ardev ./gtk2_ardour/ardev.
Pick the first one that contains a "web_surfaces" subfolder as
docroot.
This picks up where cfd95340b1 left off.
The goal is to ensure that the butler has completed all
PostTransportStop related tasks and won't meddle with transport
after exporting has started.
Previously this could happen, because realtime_stop() queues
PostTransportStop and the butler is sommoned after every
export process cycle.
Since 61e7f3176b the butler keeps calling non_realtime_stop()
every time it is woken up, until TFSM comes around and unsets the
flag in the process callback.
This cuts reverb tails and synth sounds after export.
Disabling freewheeling, continues normal processing where
export left off. This previously kept notes ringing, or reverbs
audible.
The actual issue was introduced in 61e7f3176b:
Session::non_realtime_stop() no longer unsets PostTransportStop
(other changes from that commit are not relevant).
The real issue however is a race-condition.
So far this only seems to happen on MacOS, Coreaudio.
It seems that non_realtime_stop() is called in the butler-thread
after exporting has started, even though the butler has been
paused in wait_until_finished().
Perhaps Coreaudio thread switches causes TransportFSM to
reinitialize and scheduling the butler?
The use of `usleep()` makes this rather a workaround.
However it's sufficient for the coreaudio rt thread to run
at least once.
