Need help debugging a plugin

I’m developing a VST3 synth using VS2019 and using “Audio PluginHost” for testing. So far synth is working great, except for one bug that I have starred myself blind trying to solve.

So I started with “Debug” and Audio PluginHost opens and I can play notes using a keyboard fine, but when I double-click the synth to open the editor, it throws jasserts which I can’t seem to find in what file and code line that is causing it.

First one is; juce_NormaliseRange.h;

The thread 0x23b0 has exited with code 0 (0x0).
JUCE Assertion failure in juce_NormalisableRange.h:242
AudioPluginHost.exe has triggered a breakpoint.

void checkInvariants() const
        jassert (end > start);

When I look in VS’s “Locals” window I expand “Name-this” and see that start and end values are both “0.00000000000000000”. Besides that both appears to be same value and therefore “end” is NOT greater than “start”, I looked through all my sliders and can’t find any with such an end value. But how do I find out what exactly caused it?

Ok I found the knob that was causing that problem. I had initially set it to “0” for both start and end, as it was disabled and dependent on another knob to be changed and then had it’s range range changed and enabled. But still that jassert is a bit strange, because end was NOT greater than start!


This happens mainly when code that is supposed to be called only from the message/main/GUI thread is called from some other thread (for example, the realtime/audio thread)

And the typical case is trying to call something that deals with Graphics or Components from within your processBlock()

1 Like

Assert end is greater than start means something like “make sure end is greater than start”. The condition you put into an assertion statement is always what you expect to happen. So if you expect end to be greater than start and this was not the case as you said, it’s obvious that the assertion is hit :wink:

To reiterate what @PluginPenguin said, an assert asserts that something is TRUE. If it is FALSE, then you get hit the breakpoint.

So I should not call a components repaint() from within a hiResTimer inside ProcessorEditor?

Nope, hirestimer uses a separate thread.

Yes, you shouldn’t. At least not directly. A HighResolutionTimer is running it’s own thread. But repaint() needs to access the variables of Component, that are shared with the window management, so it has to happen in the message thread.

A solution is to schedule the repaint() from the HighResolutionTimer on the message queue using:

auto safeThis = Component::SafePointer<Component>(this);
MessageManager::callAsync ([safeThis] { if (safeThis) safeThis->repaint(); });

But then you might as well use the normal Timer, that runs on the message thread and is perfectly suited for that purpose…

Ok I’ll consider using that, as I did make a fully functional 4000 line Breakout game just a month ago, doing what I explained with no issues.