Standalone plugin assertion fails


#1

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);


#2

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…


#3

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);

#4

Or using std::lround ?


#5

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?)


#6

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.


#7

I have noticed lots of == style comparisons of double and float in JUCE. It disturbs me every time.


#8

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…


#9

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?


#10

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?


#11

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.


#12

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


#13

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: