Just tried to build the standalone version of a test-plugin, and as soon as I enabled my midi-interface in the options and play a single note, an assertion in
MidiMessageCollector::addMessageToQueue () fails. The assert is
jassert (sampleRate != 44100.0001);
According the the MSVC 2013 debugger the sampleRate is 44100.0009777777777777
Wouldn’t it be a good idea to cast the samplerate to an int for the assert like this?
Has reset() been called, which is the purpose of this check. If reset() has been called it should have been called with a whole number sample rate and this check should pass…
(admittedly, not sure why this check is coded in this way, setting a flag in reset() would show intent clearer?)
I have made zero changes to a test-plugin (no code was added). All I did was use the projucer to create a project, set the “stand alone” checkbox and build.
I recently looked through all these because someone suggested fixing warnings triggered by the -Wfloat-equal flag, but all the warnings I saw seemed to be false alarms, where the comparison was done deliberately in full knowledge of how float comparison works. They’re mainly just checking whether a value has been modified from a zero initialiser value, or comparing it to a safe-to-represent constant like 1.0 in circumstances where it genuinely doesn’t care about rounding errors.
However, I didn’t see the instance mentioned by the OP, which is indeed a mistake! I’ll get that sorted out right away…
I’m still a bit confused. Now with the 5.0.1 update, i still get an assertion, but now it’s because “reset” hasn’t been called.
I don’t understand what am I supposed to do? This assertion triggers only when I hit a key on my midi-keyboard.
Who should call reset()? From where? For what purpose? Why would the stand-alone version of an empty plugin (essentially the “Hello World” dummy plugin that get’s created by the projucer) require any code changes to work as stand-alone?
If you’re building a stand-alone player then it should get called in AudioProcessorPlayer::audioDeviceAboutToStart(). Does that not happen? Maybe share a some test case code that fails?
I didn’t write any audio code at all. I simply used the projucer to build an audio-plugin and set the checkboxes for stand-alone, vst2, vst3 etc.
The projucer then creates an empty audio-plugin with “Hello World!” In the editor. When then selecting a midi-input from the options and hitting a key on the midi-keyboard, the assertion is triggered.
I get this too, but only on an iOS standalone - as I’m not really bothered about sample rate for my app I just commented the line out and everything works fine (not a great solution I know, but I raised this a few months ago and as no-one else seemed to be seeing the issue I just assumed it was something funky with my setup - intended to loop around but you know how things are…).
It appears this problem of messageCollector.reset not getting called is still happening (or happening again perhaps?):
I’ve just compiled the ArpeggiatorPluginDemo from the PIP file ArpeggiatorPluginDemo.h unmodified from the JUCE\examples\Plugins folder of JUCE 5.4.4. I’ve compiled and run the standalone plugin, and get the jassert failure:
jassert (hasCalledReset); // you need to call reset() to set the correct sample rate before using this object
This is at line 51 in juce_MidiMessageCollector.cpp .
I’ve set a breakpoint at line 201 ( " messageCollector.reset (sampleRate);" ) of juce_AudioProcessorPlayer.cpp, but the code is not executed, neither when the program is first run, nor when the audio/midi settings are set, nor when I play a note on my midi input device (which is when the jassert failure is triggered).
To reproduce:
Create projucer project from ArpeggiatorPluginDemo.h in JUCE 5.4.4
Export to Visual Studio 2019
Build and run debug standalone plugin (the default)
Set audio/midi options
Play a note on the midi input device.
I’m using the current latest non-beta version of Visual Studio 2019 on Windows 10 x64 version 1903,