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.
Some refactoring was necessary to avoid code duplication
Restoring of device state for input and output devices still doesn't work
correctly. I'm not quite sure what the issue is at this stage.
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... :)
Thanks to brilliant detective work by John E. we
can now reveal that the actual crash in
EngineControl::print_channel_count() is caused
by a seemingly unrelated exception.
The root cause however is waves/ASIO backend reporting a
buffersize that is not in list of available buffer-sizes
it reported earlier.
connect/disconnect button was connected multiple times
Also the button allowed to start a backend with
invalid settings (after changing backend).
Q: does “Connect to” make sense? It’s redundant with
“Apply”.
fixes crash when jack is started externally
and the dialog is displayed later.
The current state e.g. avail buffer sizes is not
are queried from the backend, Apply,OK -> crash
because the dropdown is empty)
When the i/o channel spinbox widgets are realized, they call
print_channel_count(). A "0" is formatted as "all available channels".
This causes the GTK::Entry inside the spinbox to emit a "changed"
signal which in turn triggers a parameter_changed(), [..], store_state(),
which calls into the spinbox again while it is being realized,
which makes gtkmm barf.
Start Ardour with JACK running (autoconnect to jack), Window ->
Audio/Midi settings -> initial no_control_notebook. Change
Audio System -> [control widgets are realized] -> glibmm std::exception
./waf i18n warns about passing an empty string to _(). Actually, the code
in question just wants to make a label not appear, so it might as well
just hide or show it as appropriate rather than attempting to set its
text to the empty string.
