Where to load samples


#1

I know there is already a thread covering this subject floating around somewhere but I didn't find it, so quick question:

Where should I load the samples of my plugin? Loading in the constructor of the Audioprocessor is bad, because it is called at some host's startup  which is annoying, and in prepareToPlay it would be reloaded everytime the sample rate changes.

I could add a initialisation flag to prevent reloading in prepareToPlay but maybe someone has a better solution.

Of course I am loading the stuff on a seperate Thread, but I still have to start it somewhere...

thanks!

 


#2

If it's on a thread, then starting it in your constructor is fine. Just make sure it can be quickly interrupted if the plugin is closed before it has finished.


#3

I am using a ThreadWithProgressWindow for this, so I think it should be ok (I assume I handled the threadShouldExit() stuff correctly)

But it still bugs me a little bit that the samples are loaded each time the host starts up - right now there are not many samples and I can hardly see the Popup window of the loading thread (also because of the speed of the overly awesome MemoryMappedReader), but this could change in the future, so I will have to think of another solution.

Thanks!


#4

Bumping this because I ran into a weird issue.

Starting a thread in the plugin’s constructor using a ThreadWithProgressWindow that loads the samples causes auval to fail on certain machines (not mine) with this error:

CGSConnectionByID: 0 is not a valid connection ID.
FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF

After some digging I found this post:

So if this is the problem, then auval crashes because the ThreadWithProgressWindow class adds a modal window to a command line tool (auval).

A possible solution might be something like a ThreadWithOptionalProgressWindow class, which does not popup a modal window on the desktop but adds it to a given parent component (the plugin editor) if it exists, or does the job silently (when nullptr is passed as parent component).

Has anybody made similar experiences using ThreadWithProgressWindow in a plugin’s constructor?


#5

Absolutely never use ThreadWithProgressWindow anywhere in a plugin!!

It uses a modal loop, which is poisonous in a plugin host. Just create a component (as a child of your plugin editor, preferably) that is asynchronously modal, and hide it when your thread has finished.


#6

OK. I started replacing this class anyway.

Do you think a asynchronous modal ThreadWithProgressWindow variation would make a useful addition to the JUCE codebase?


#7

Yes, it probably would!


#8

Alright, I’ll try to make my class as generic as possible and share it once it’s ready - I assume you have other things to do :slight_smile: