Problem with nyquist assert

Im trying to make a filter from the Audio Programmer on YouTube in an Audio Application using dsp which is imported as a module.

I followed everything that he did however upon trying to compile I get this jassert

jasssert(freq>0 && freq<=sampleRate * 0.5)

which im assuming is the assertion for the Nyquist of the filter… however upon initialization of the processor duplicator in the MainComponent I have the frequency at
and the sample rate at

so the frequency is for sure above zero and is less than the Nyquist…

any help on debugging??


try to use brackets to separate your boolean operations, I think, that should fix it.
Additionally I would recommend to specify variable types more directly. E.g., instead of writing “freq > 0”, write “freq > 0.0f” to be sure you compare a float and a float.


@koerthawkins This is original juce library code and not code written by @JEsca1997 so I wouldn’t search the problem in wrong brace placement here :slight_smile:

If your debugger stops at that line you can usually inspect the values of each variables in that state. So the first thing to check is if freq really is 20000 as expected and sampleRate is really 44100 as expected. If not, you can usually step up the call stack in the debugger to figure out which function called this one and step up the call hierarchy this way. You can always inspect variables in all these higher call steps until you find the point where the unexpected value has originally been created. In most of the cases this will answer your questions.

Good luck with debugging :slight_smile:

ill try to use a DBG in the method to check the init parameters.
I think do a set Range in the main method would suffice…

also I had to create a new audio device manager to get the output channels for the spec.

for some reason it didn’t want to use the one that was pre-installed??? IDK. But it works now atleast but I made a new thread for another problem I had regarding the Component header message lock with my Speakers…
if its not one thing its another :stuck_out_tongue:

No that is not exactly what I meant :wink:

Do you actually know what a debugger is? It’s a piece of software that allows you to stop your code during execution and look into variables (even change their values) etc. Without knowing how to use your debugger you will be lost creating more complex projects, trust me :smiley: So better take some time and learn to use the debugger. Which IDE do you use?

Oh you meant like set break points, examine zombies etc etc in Xcode or Visual studio?

I was thinking DBG the values in the method calls when they get added to the stack.

Yes, a jassert works just like a breakpoint – your code will be halted in the debugger. I just created a stupid example in a project I’m currently working on with adding the line jassert (1 == 2) which will of course always fail. This is what happens when I execute that code under the debugger. Note that my IDE is JetBrains CLion, so this might look different in your IDE (this is why I asked which one you use), but you’ll find the same elements in your IDE as well.

Let’s check what we are seeing here. First of all, we see the blue code line with the red flash icon beneath it in the line were I added this assertion, that tells us that we have stopped at a breakpoint here.

Whenever you halted at a breakpoint you can inspect two things, which you’ll find in the lower section.

The call stack

You find that in the bottom left corner. There you see how the code flow reached this line of code at all. For an example we see that the function OJDAudioProcessor::prepareRessources we stopped in has been called by jb::PluginAudioProcessorBase... which again has been called by juce::VST3Component::preparePlugin and so on (we can even see code outside our plugin here, e.g. functions that the host called, which are greyed out here). All those steps are so called stack frames and each upper stack frames saves it variable states. More on that below…

The variable inspector

On the bottom right we see our variables. We see three bools and one const float here and we see their exact values. For structs like e.g. spec which is a juce::dsp::ProcessSpec we see this tiny triangle icon on the left which would open up a sub-view through which we could see the values of all members of this struct. We also see the this pointer here, which is a way to look at member variables in the class we are currently in.

Jumping up the call stack

Now if you click on the previous stack frame in the call stack on the left you can jump into that function and you’ll see the variable states in that stack frame and all other previous functions there. This way you can usually find out very quick how a certain value reached your function.

Now in your case I’d first inspect if either freq or sampeRate has an unexpected value. Then I’d try to jump up the call stack and see where it came from, which will hopefully lead you to the original source of this bug. I hope this helps you a bit.