Many many thanks for the update. Much improvements.
I was hoping that the bluetooth headphone issue would be resolved. Ulf said this was a trivial issue. Maybe It’s not so trivial after all?
I can’t recall having said that it’s trivial to fix. The issue is still open in our bug tracking system as someone has to find the time to fix it. And it is actually not only a Dorico issue but also affects Cubase and Nuendo.
Since there is the workaround with the aggregated device we have not put high priority on this issue, that’s why it is still not fixed. Is it really such a pain for you?
With the previous version it was causing the engine data file to get corrupted every time I switched between the AirPods and the regular outputs or if the AirPods hadn’t connected yet. Maybe this won’t be a problem with version 1.1, we’ll see.
So, I’ve been using the bluetooth headphones for several days now. Works much more reliably than before. I’ve not experienced a crash or bad enginedata file. But one problem still exists (other than detecting the difference between output and input). If the headphones are not connected before launching Dorico, once you try to set the audio device to the aggregate device, Dorico becomes non-responsive and you need to force quit it to get it working again. Dorico is not recognizing the new audio device that became connected after launch.
If you connect the headphones before launching Dorico, then it will recognize that the device you are trying to connect to exists and will proceed as normal.
I will have a look tomorrow…
I can reproduce the issue with Dorico becoming unresponsive.
This is somehow related to BlueTooth devices, because something similar I can exercise where my UR device participates in an aggregated device. Well, it also doesn’t work as smoothly as one would expect, but at least Dorico doesn’t become unresponsive.
I’ve logged this issue as STEAM-6482 in our bug tracking system.
Thanks for confirming.
Something I find useful is look at what other programs do in these situations.
For example, Logic Pro X when it sees a new audio device come online when the program is already running, notices it immediately and asks if you want to use that device. If so, it allows you to set it as the active audio device.
If you quit the program with a device active and then relaunch it when it is not active, it presents you with a dialog that says: “The last selected audio interface is not available. The previously selected interface “Built-in Output” will be used for this session.” If sometime later the device that was used does come online and that device is in your sound preferences as the preferred output device, then it just switches to it immediately.
Final Cut Pro X does something similar but without notification, it just switches between devices automatically. Sibelius also just switches automatically between devices.
For what it is worth, SONAR does much the same thing.
On auto switching devices…
Nice feature, but if Steinberg implements it in any of its DAWs, please put a box in preferences so a user can disable it if desired. A device black-list is also nice to have…I.E. set things the app should ALWAYS totally IGNORE.
In Core Audio, the auto switching only happens if you select a device in sound system preferences to use a device that comes and goes.