How to tell if a plugin is scanned only

This most likely came up before but I was unable to find it.

Is there a way for a plugin to tell whether it’s just being scanned, as opposed to being loaded for actual use? My plugin needs to extract big files before first use (uncompress sounds), which can take a minute or so. Doing this during a scan might not be ideal, so I wanted to postpone it until the plugin is actually loaded for use.

Is this information available somehow? What would be the ideal function to hook into?

I doubt that this is possible, but I’d anyhow propose that you do the files extraction in a separate thread if it can take that long, so the DAW is not blocked for a minute during plugin initialization.

Maybe use a timer that starts the file extraction process after 1 second of delay or something? During the host’s plugin scanning phase, the host typically very quickly creates and destroys the plugin instance, just to get some basic information out of it.

1 Like

Thanks for your replies so far. Since it looked impossible to do in the constructor, I’ve solved this another way, by means of a ensureSoundDataAvailable() method that is called on prepareToPlay(), getStateInformation() and setStateInformation().

A secondary thread is not an option, as the uncompressed data is required at the time the above functions are called (at the latest), or the plugin would not work.

I’m glad now I don’t need to hack shell scripts for different OS and installer platforms to do this at installation time.

You know you became a Juce addict once you prefer hacking C++ against even thinking about a shell script :wink:

I’m still having issues popping up some message dialog during extraction (won’t show up), but that’s another thing.

There are always many ways to Rome, so it is up to you.
But the prepareToPlay is called from the hosts GUI thread. If you block that thread for a minute, as you wrote in the first post, the complete host is unresponsive for that period. I would probably consider the last plugin I installed as broken and uninstalling it, before it ever got it’s sounds downloaded.

Maybe you can serve a better user experience by displaying “Downloading sound files” and just don’t play back until the files arrived?

Some hosts might call those functions during the scan stage, though…(It’s always best to be prepared for all kinds of madness that the host applications may do.)

Well I wouldn’t call this madness, as a host, you want to check as much of the plugin a possible during a scan. If a plugin is going to crash as soon as you call prepareToPlay or get/set state, it deserves to be blacklisted!

1 Like

To the OP, your plugin should load as quickly as possible and not block the host at all. If you need to load resources, these should be on a background thread and you should show the user progress of loading (look at how Kontakt does this for a good example). It’s better to produce silence for a bit whilst this happens rather than block.

You can check if a plugin is rendering (AudioProcessor::isNonRealtime) if you need to block before samples are loaded.


Thanks everyone. Your help is appreciated.

Developing on SSD, I first expected the process to be way slower on hard drives, but it turned out to be merely around 10 seconds on average. Since it’s an installation task that’s only run once and never again, I was fine with a message box showing its progress and called it a day.

Should this process be triggered during a scan, it should not be too disrupting either.