Window generation when loading state or preset for given plugin

[psuskin]

I've seen multiple discussions and source code comments pertaining to calling open_editor or creating a temporary window in order to load all parameters for a given plugin. I've experienced this first-hand with Serum, which doesn't load "OSC A" without one of these solutions. This doesn't pose a problem when using dawdreamer locally. However, when running my dawdreamer script on my FastCGI server, window generation isn't possible and causes the execution to halt. Are there any proposed ideas for workarounds that don't involve window generation or that could theoretically run on a server?

[DBraun]

Oh that's very interesting. I hadn't noticed that with Serum. OSC A is usually the primary one generating sound. So if you call load_state with Serum, is the OSC A the default sawtooth instead of what had been saved? I'm not sure about servers and this issue. I think we just need better usage of the JUCE-related code there...

[psuskin]

These are the results of 2 subsequent open_editor calls after calling load_state. It's important to note that this is only the case for my fork of Dawdreamer, since I commented out the line responsible for generating a temporary window in loadStateInformation: StandalonePluginWindow tmp_window(*this, *myPlugin); in favor of merely running the dispatch loop: juce::MessageManager::getInstance()->runDispatchLoopUntil(10);. The official dawdreamer is perfectly capable of loading all parameters on load_state() thanks to the window generation. I don't know how I'd exactly go about finding a workaround for the window generation, so I was wondering if you had any ideas.

[psuskin]

I managed to find an ideal solution. One must simply call juce::MessageManager::getInstance() at the beginning of a given script, and everything works perfectly, even without window generation.