View Issue Details
|ID||Category||Date Submitted||Last Update|
|0008050||features||2020-04-24 18:18||2020-04-29 23:35|
|Reproducibility||have not tried|
|Platform||GNU/Linux x86_64||OS||Debian||OS Version||sid|
|Fixed in Version|
|Summary||0008050: Add a “Cancel” and/or “Back” button in the “Audio/MIDI Setup” window|
|Description||After launching Ardour and opening (or creating) a session, the “Audio/MIDI Setup” window is displayed. If that window is closed through the window manager close button, Ardour exits, which could be confusing for the user because after clicking on opening a session (or creating a new one), this window could be unexpected, making the user to close it, resulting in a strange situation when nothing will come up next.|
In my opinion, it would be nice to have an “Exit” button to make clearer what would happen if clicked. Another suggestion could be to have a “Back” button to let the user go back in case a wrong session was selected.
Finally, I think this issue could have more sense if you have in mind bug #, which proposes to have an “Accept” or “Continue” button in that window.
|Tags||No tags attached.|
||The last paragraph refers to bug 0008049.|
||The general idea is to avoid any "close" buttons if the Window manager already provides one.|
Not sure of your precise workflow here.
If I start Ardour with:
* not previously using JACK
* "Autostart" disabled in Audio/MIDI setup
then after selecting a session to open the audio/MIDI setup dialog appears.
If I "finish" this dialog using "start", and that is successful, the audio/MIDI setup dialog vanishes.
If I use the window manager close/delete button, then yes, we consider an indication from the user that they are quitting the program (since "Start" is the only acceptable "next step").
@paul, since JACK does no allow to change systemic latency while jackd running, the engine is stopped after calibration (and Ardour does not proceeded to load the session).
With Ardour/ALSA the engine is kept running after latency calibration, and since there's no explicit "Continue" button, Ardour needs to proceed.
||I was testing it with ALSA, but without calibration. Just start -> select session -> audio/MIDI setup -> configure -> [ Start ]|
@x42, regarding " The general idea is to avoid any "close" buttons if the Window manager already provides one. ", I would say that when I launch Ardour, the "open session / new session" window pops up, which has three buttons: Quit, Back and Open. Back is disabled, and it will be turned on if the "New Session" button is clicked.
I think that window has a nice workflow, because someone can think that you are not really into the program yet (no "main"/editor window displayed), so these buttons help to guide the user in the way.
So, if you think about these two windows like an startup assistant, you might miss some buttons in the second one (audio/MIDI setup window); i.e. a sort of assistant bring you here, but you have to guess how to continue.
However, since the audio/MIDI setup window does not have a "Continue" button, there are two ways to let Ardour proceed:
- ALSA/JACK (ran by Ardour): Clicking the "Start" button.
- ALSA: Calibrate the audio and when button "Use results" is clicked, Ardour will understand it has to proceed.
- ALSA: Calibrate the MIDI and when button "Back to settings" is clicked, Ardour will surprisingly start the audio engine and proceed (see my note in 0008049).
- JACK (is already running): Clicking "Connect to JACK" button.
So, I would say that every of these buttons has two actions. And the action of "going to the editor" can be performed by clicking in one of these 4 buttons (well, 3 if you are using ALSA). That's why I think that a "Continue" button will leave every of these button with only one action; their specific task (i.e. start ALSA/JACK engine, use that audio calibration results, use that MIDI calibration results, or connect to already running JACK server). And it will help to let the user know how to proceed.
Once again, calibration is not intended to be used regularly. It is not semantically equivalent to "Start" or "Connect to JACK".
The "bug" (to the extent that it's a bug) is that the "Calibrate" button(s) have made anyone (such as yourself) think that they are semantically at the same level.
I believe that x42 has already outlined our general thinking about how we plan to address that.
There is only 1 button to continue in the audio/MIDI setup dialog, and that is labelled either "Start" or "Connect to JACK".
I agree that calibration is not intended to be used regularly. But I am forced to do it every time I launch Ardour because of the USB audio interface I am using. Maybe is time to switch audio interface.
For the record, I did not classify this issue as "bug", neither 0008049, I just selected "features". I quite agree with the current behavior of the dialog, but I thought it could be improved, and I wanted to share my thoughts with you guys. So, thank you for read them, and I really appreciate your explanations and time.
Finally, it has made myself think that they are semantically at the same level because they start the engine and go to the editor. That is only what I was pointing as confusing. But if "calibration" is out of the equation, because it is seldom done. Then yes, there is only 1 button to continue, as you said.
||If using the "calibration" button starts the engine in a persistent way and goes to the editor, that's a bug. That is not intended behavior. Calibration is a process that requires having a running engine for some period of time, but when complete, the engine should be stopped, and there should be automatic "onward step" to the main window(s).|
Well, for me "it is not a bug, it is a feature", because I can do the calibration of an USB audio interface and launch Ardour in the same "cycle", keeping values consistently. Stopping the engine would make these values be outdated. That's why I cannot calibrate that device with JACK and jack_iodelay: the values obtained with jack_iodelay are not valid when running JACK for the second time (using -I and -O parameters).
So, I guess that the bug is somewhere in the USB audio kernel driver and/or device's USB protocol implementation.
|2020-04-24 18:18||agus.terol||New Issue|
|2020-04-24 18:21||agus.terol||Note Added: 0023900|
|2020-04-26 23:13||x42||Note Added: 0023941|
|2020-04-26 23:19||paul||Note Added: 0023943|
|2020-04-27 00:20||x42||Note Added: 0023946|
|2020-04-27 00:39||paul||Note Added: 0023947|
|2020-04-27 19:23||agus.terol||Note Added: 0023967|
|2020-04-27 19:29||paul||Note Added: 0023968|
|2020-04-27 19:51||agus.terol||Note Added: 0023971|
|2020-04-27 19:58||paul||Note Added: 0023972|
|2020-04-27 20:15||agus.terol||Note Added: 0023975|