Host + VST strange startup bugginess on loading previous session

We have a standalone sampler app that is a VST host plus VST. On startup, the app will load the most recently saved session and can also open and load saved sessions by double-clicking on session files.

The issue I’m seeing is that, on OSX, if the session that gets loaded is a particularly big one (with lots of samples to load), the app will not startup properly and we’ll see lots of strange behavior and bugginess - some UI elements and PNGs won’t load properly, a certain http call will crash (only on osx 10.10), samples won’t finish loading, etc.

I believe I am properly loading the session on an async call as Jules shows in the VST host example app, heeding the note:

    // to re-open a file and instantiate some plugins, it will happen AFTER this
    // initialisation method has returned.
    // On Windows this probably won't make a difference, but on OSX there's a subtle event loop
    // issue that can happen if a plugin runs one of those irritating modal dialogs while it's
    // being loaded. If that happens inside this method, the OSX event loop seems to be in some
    // kind of special "initialisation" mode and things get confused. But if we load the plugin
    // later when the normal event loop is running, everything's fine.

But, the problem persists.

I’ve added specials calls to the VST to test that it has fully loaded and I’ve tried various length sleep() calls in the async loader class before loading the session, but it seems to not fix it 100% of the time.

The strange part is that the behavior seems to be OSX and computer version specific. I’ve seen that on most computers, the first startup of the app loads fine, but then if you close and re-open the problem occurs. In some cases, if I simply rename the .app it will work again on the first launch. On other computers, it will load perfectly fine every other time you open the app.

I’m wondering if there is some kind of app specific caching that is happening on mac that is interacting with the startup routine?

I’m really not sure what to try at this point.

I’ve debugged the session loading code in general and I believe its pretty solid. The sessions load perfectly fine if you start up the app with a blank session and then load a large session after the fact. The issue only arises when you ask the app to load a large session right at startup.

Any clues are appreciated!


I don’t see how sleeping on the message thread would help here. The issue in Jules’ comments requires the message thread to be able to process events and when sleeping you will be blocking the event loop. Rather try using Timer::callAfterDelay.

Also I assume you have tried running your app with address sanitiser enabled?

Finally got around to looking at this again.

It looks like using Timer::callAfterDelay has fixed the issue. Though its a bit unclear to me how to know how long to wait. I’m having it wait a second before loading the session data, which is not an unacceptable delay, but might be longer than it needs to be.