Description

Add to our (and MSS's) plugin scanning dialog,

a skip button, like in AU3:

Figma link

Unfortunately will probably be more challenging than it seems.

Motivation

Some plugins can take a long time to load. The user may want to skip on that particular plugin but continue scanning the rest of the plugins normally. At the moment this isn't possible.

Also, the existing "Cancel" button is relatively inefficient in this particular case, because the scanning will only get cancelled after the loading of the current plugin is finished. The user may get annoyed at a particular plugin, but will still have to wait for it to finish loading, and then the scanning of the following plugins, which may be needed by the user and well behaved, will get cancelled.

Note that the discussion around the need for a skip button probably arose from the MuseHub-distributed plugins and the built-in mechanism that starts the hub, attempts a sign-in and queries the plugin permission. This takes several second for the first scanned MH plugin.
The MH team is however planning the release of a slicker, background service that handles this, which allegedly should make the procedure significantly faster. When this is released (Q3 2025 if all goes well), the need for the skip button may well become less prominent.

Alternatives

cloud-sync-like scanning

We could consider making the scanning completely asynchronous, with a small, docked progress bar in the UI, similarly to what is done for Au3's cloud sync. This would require a design, and would probably be more work because the application logic would have to deal with in-between states (when do the effect menus get populated or updated, etc), but may be worthwhile given the UX benefit.

How we do it currently (without the skip button)

The frameworks IProcess offers a way of spawning a process synchronously: it blocks the thread it's called on (atm the main thread) until the process is finished, and retrieves the return code.
We use this for the scanning: for each plugin, one at a time, we spawn an Au4 (without UI) process, telling it to try and load the plugin. The return code indicates if all went well or if it crashed.

How we could do it with the skip button

Add an asynchronous, "killable" option to IProcess

When receiving the "skip" signal from the UI, one thing we could consider is killing the ongoing process.

For this we'd have to:

1. extend the framework's IProcess implementation with an option to spawn a process asynchronously and give the possibility to kill it. This extension would have to be committed to the framework,
2. integrate this more complex scenario in Au4 (and at a later stage in MSS)

It looks likely that the Qt library (already used by the current implementation) offers this kind of control, but this hasn't been verified.

Give up on the ongoing process

Alternatively, the "skip" signal could be used to give up waiting on termination of the spawned process.

We would use the framework's IProcess as is, but execute it in a parallel thread, using a condition variable to wake it up and rejoin the main process if the "skip" signal arrives.

Things to consider then:

• IProcess allows starting a process in the background, I don't know that it provides signaling for when the process terminates. Likely the underlying Qt library does, but this must be verified.
• atm, the spawned processes are executed one after the other, which makes the write access of known_audio_plugins.json by these safe. Now it'd be possible that skipped and follower processes try to write to the file concurrently. To solve this, we could ask those subprocesses to write to a personalized file. The main process could then update known_audio_plugins.json by itself, on successful termination.
• the spawned process could become a zombie process: in the unlikely even that it freezes, the user would not notice now but could still see an Au4 process in her task manager after the application is exited.