OK, tried that, yes this one works, but not mine. And trying to debug didn’t help, the WASAPI or DirectSound callback is not even hit.
So I went again, started from scratch. The standalone plugin required that I added by hand a new module in JUCE, and now it fails in AudioProcessor with:
jassert (success && newNumIns == getTotalNumInputChannels() && newNumOuts == getTotalNumOutputChannels());
Which is something I’m wondering. I’m using the string method to describe the supported configuration (JucePlugin_PreferredChannelConfigurations activated), and I’m wondering if something wrong is going on under the hood of the standalone version.
As the demo plugin seems to be working, there is something going wrong with your code or the way you define JucePlugin_PreferredChannelConfigurations. What value does JucePlugin_PreferredChannelConfigurations have?
Ahh there you go. By default, the standalone plug-in disables microphone input (as this could cause a nasty feedback loop). But your plug-in does not support any configuration where there is no input. Try adding configuration with no input. For example, try the following:
Isn’t that forbidden in the default configuration, where you return false if you don’t have the same number of inputs and outputs? Which would be the reason why you get an assertion error in debug mode?
Yes, that’s what I’m saying. But the configurations you advised me are not valid in that method, or did I misunderstand it? It states that you require inputs, so it’s 1,1 or 2,2, but not 0,1 or 0,2, which you said is what the standalone plugin mandates to support (I tried them, but didn’t change a thing, the audio thread doesn’t run at all).
So I’m confused. And this doesn’t address the fact that the default/freshly created standalone plugin crashes in debug mode on an assert.
Sorry I should be more clear. In JUCE you either choose to use the JucePlugin_PreferredChannelConfigurations define or override isBusesLayoutSupported. In any case, if you are using the standalone target, then you need to alter your plug-in so that it supports zero channels as an input. This means that you would have to alter the Projucer’s audio plugin default template code to also support zero input channels, when adding the standalone target to the project.
If you are using JucePlugin_PreferredChannelConfigurations then you should include layouts that have an input count of 0. If you are using isBusesLayoutSupported, then you want to return true even if the number of input channels are zero.
In your case (as you are using JucePlugin_PreferredChannelConfigurations), as stated above, you need to change your code to the following:
Thanks for the precision. Anyway, that doesn’t help, this is not the cause of the issue. Even when changing the parameters, the audio thread doesn’t run.
I would suggest that you change the default project if what you are saying is true, because having a project that by design raises an assertion without having any explanation as to why doesn’t make sense.
Then I can’t really help you. You’ve confirmed that the demo project works for you, so I’d use this as a starting point. If you are using the default generated project then you will need to alter the project in the way I’ve outlined above.
There is something that stops the audio thread outside the plugin, that I don’t have “access” to, and that I have no knowledge of. The JUCE frawework stops that thread, not my plugin.
Anyway, if the requirement for a standalone app is to have 0 inputs, I wonder the point of having it. Or rename it to standalone synth at least.