see man 3 dlopen. Ideally we’d use RTLD_DEEPBIND,
but it’s neither portable and rather new (glibc 2.3.4).
This fixes issues with symbol conflicts in plugins
e.g. http://pastebin.com/FkFkf3Mm (plugin expects
its own OSC[illator?] class but gets ardour’s
OpenSoundControl instead).
towards fixing #6238 and #6096.
GUI thread:
#2 Glib::Threads::Mutex::Lock::Lock
#3 Evoral::ControlList::eval
#4 Evoral::Control::get_double
#5 ARDOUR::AutomationControl::get_value
#6 ProcessorEntry::Control::control_changed
..
#15 PBD::Timer::timeout_handler
at the same time: Audio Thread (try-lock, fails)
#0 Evoral::Curve::rt_safe_get_vector
#1 ARDOUR::Amp::setup_gain_automation
#2 ARDOUR::Route::process_output_buffers
Due to the failed try-lock.. AMP::_apply_gain_automation
is false. and Amp::run() uses a different gain factor.
-> click.
For some reason we don't understand 'push_state_to_backend()' can interfere with hiding the dialog (causing a partially hidden dialog to remain on screen). It's most likely a timing issue with the Windows version of GTK. Fortunately, reversing the calling order seems to fix it - BUT...
If there's no session loaded yet, the user can be left with a very long wait while nothing seems to be happening. The next thing the user would normally see would be the splash image. So let's display it slightly early (so the user can at least see that something's happening).
Sadly, it's all very kludgy - but a lot better than what we had before... :)
Mixbus in particular uses both types of tooltip so we might as well make them look the same.
N.B. The appearance is fine now on Windows but needs to be tested on the other platforms (i.e. some tweaking might be necessary).
All canvas objects share just one tooltip object which is based around Gtk::Label. The Label expands if the current tooltip text is wider than the previous text. However, it doesn't shrink again if the next tooltip has shorter text. Eventually, this results in some very strange looking tooltips (especially in Mixbus where they're used quite extensively).
Deleting the object after use will force a new object to get generated next time (at the correct size). There's still only ever one object per canvas but it's no longer persistent.
This reverts commit 6ba555c2f5.
which does not yet take monitoring states into account.
Ideally the case handled here should not happen in the
first place, It should be fixed in session_transport
transport_sub_state.
If there's port-latency > period-size, there is a
split cycle with (this_event->action_frame - _transport_frame).
Yet Session::check_declick_out() keeps PendingDeclickOut if
StopPendingCapture is set. The route declick’ed twice:
Once with the period-size and one with the remaining frames,
which resulted in a click.
