Standalone plugin assertion fails

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?

jassert ((int)sampleRate != 44100);

That’s one solution. Problem here is the floating point comparison; JUCE outta be using some epsilon based comparison.

GLM provides good functionality to accomplish this: https://glm.g-truc.net/0.9.4/api/a00146.html . Now if only juce did…

1 Like

wow, 8 years that was lingering. I don’t know if I find that funny or scary, it begs to break… :wink:

which would still fail at 44099.99999999. Maybe:

jassert (fabs (sampleRate-44100.0) < 0.01);

Or using std::lround ?

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 have noticed lots of == style comparisons of double and float in JUCE. It disturbs me every time.

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…

1 Like

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.

Nope, that works fine for me. I can’t see any way that it could play without AudioProcessorPlayer::audioDeviceAboutToStart() being called first.

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 was the bottom half of this thread:

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:

  1. Create projucer project from ArpeggiatorPluginDemo.h in JUCE 5.4.4
  2. Export to Visual Studio 2019
  3. Build and run debug standalone plugin (the default)
  4. Set audio/midi options
  5. 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,