EngineControl::set_driver_popdown_strings is now like the other
set_*_popdown_strings methods in that it sets the driver strings and a
default active entry and returns false if no drivers are available.
The fix does not work properly anymore for the Portaudio backend and needs
fixing in another manner. It will now be temporarily back to the broken state
it was in before the "fix".
This stops a whole lot of redundant signal emission and makes it much easier to
think about what is going on. It also makes the dialog present much faster.
AudioBackend::enumerate_drivers is not supposed to be called for backends that
don't support driver selection. The wavesaudio backend asserts if the method is
called.
Connect to the backend_combo changed signal after setting state as calling
backend_combo.set_active_text() in set_state was triggering backend_changed(),
which would then see the driver_combo had not been set and set it to the
incorrect value.
The value/name of the backend needs to be restored first then we can populate
the driver combo and set the correct active entry from the saved state. After
which backend_changed() will populate the device combo's etc so they can then
be set to the correct active values from the saved state.
This is not a real fix; just a stop-gap for the worst offender.
iostream on OSX is not thread safe.
Sadly no crash report so far managed to catch the 2nd thread in action.
looks like the GUI thread is preempted, 2nd thread succeeds, and the
crash occurs later).
see also https://discussions.apple.com/thread/3479591
crash in
s << c->internal_to_user (c->get_value ());
ardour-4.1.335(5000,0x7fff777f5300) malloc: *** error for object 0x7fe2f3e06170: pointer being freed was not allocated
1 libsystem_c.dylib abort + 129
2 libsystem_malloc.dylib free + 428
3 libsystem_c.dylib __numeric_load_locale + 544
4 libsystem_c.dylib loadlocale + 216
5 libstdc++.6.dylib std::__convert_from_v(int* const&, char*, int, char const*, ...) + 193
6 libstdc++.6.dylib std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_float<double>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, char, double) const + 193
7 libstdc++.6.dylib std::ostream& std::ostream::_M_insert<double>(double) + 221
8 ardour-4.1.335 ProcessorEntry::Control::set_tooltip() + 854 (processor_box.cc:578)
9 ardour-4.1.335 ProcessorEntry::Control::control_changed() + 446 (processor_box.cc:637)
10 ibpbd.dylib PBD::StandardTimer::on_elapsed()
see 87b89a6
IMPORTANT NOTE: In theory, the correct glibmm function should have been Glib::filename_from_utf8() but I couldn't make that work on Windows and
ended up using Glib::locale_from_utf8() instead. sfdb import will therefore
need to get re-tested on the other platforms (especially in a non-English locale).
If this fix doesn't work we should probably revert to the previous strategy
but using the global specifier "::g_open()" explicitly…
… and only on PLATFORM_WINDOWS (POSIX #define g_open open) fails regardless.
