When I build my plugin testwise (for debugging purpose) as standalone the first ~20(?) render calls seem not to be able to process anything in a timely matter. Even if the test process is a very simple one; i.e. only return data from a wavetable. After that initial phase it processes stable as expected (and as known from processing as plugin).
(mac mini @ macOS 10.14.6; samplerate, I/O size, release vs. debug build don’t matter)
Though you might not have seen this since I doubt the standalone mode is useful for anything else then debugging, being able to rely on it would be nice, since such things do cost a lot of time to investigate whats actually going wrong, while usually one tends to suspect its own code…
Presumably this is because the standalone plug-in is opening an audio device and then immediately starting playback, whereas the same plug-in running in a DAW is using the audio device which has already been opened by the host. I’m not sure there’s much we can do in JUCE if CoreAudio takes a few render callbacks to warm up - if it’s really important that your
processBlock calls are stable from the start you could try delaying your processing for a few calls.
Thanks @ed95, sure there is an (easy) workaround for this. I just reported this bug since when using third party software one expects to take off its debugging burden and to work. If its not working and one first needs to find out whats causing a certain bug and wether its my own fault or something else it costs some time and frustration, which I expect to be freed by using third party software. So if its a macOS flaw I would expect to have the framework owner reporting it to Apple and inform its users about issues and progress.
So at least I would suspect you to check your software wether its your fault or not, and report back your findings. Because still it could be something I am doing wrong.