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?
Interesting. I was hoping this would also cure the MidiMessageCollector::addMessageToQueue() assertion I see on iOS standalones, but unfortunately not.
If you are talking about isBusesLayoutSupported then isBusesLayoutSupported won’t even be compiled when JucePlugin_PreferredChannelConfigurations is defined due to the #ifndef in your code.
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:
If you were using the isBusesLayoutSupported you would change the default code generated by the Projucer to also return true if there are no input channels.
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.
So actually had kind of a similar thing happen to me the other day, as outlined in this post:
Although in looking into it further, it seems that this may not be the correct fix, as described in your answer here:
I’m not sure which one is the correct answer. In my experience over the last few days you have to do BOTH JucePlugin_PreferredChannelConfigurations AND isBusesLayoutSupported for VST/AU to work correctly in all cases, but this post seems to indicate otherwise?
I was running into an issue on a customer’s machine where when they would build/run the stand-alone Audio Plugin, their machine kept throwing jasserts when I tried to configure the audio settings. Even using the Default windows Audio device would throw these errors. I have no idea where to start debugging for this. Any ideas?
