I'm having trouble updating a parameter in the treestate

[Stevezee]

I’m working on an eq as one of my first projects and one of my parameters won’t report to the treestate
for some reason and I’ve tried everything but I’m stuck.

I’ve plotted the response curves using the getMagnitudes… everything works great with the sliders but I am trying to incorporate handles that can be dragged to control the gain and frequency of the bands. I’ve mapped the x and y position of the mouse/handle to the gain and frequency parameters for one of the bands and so far the gain (band1Gain) is being updated in the treestate with setValueNotifiyingHost, per the debugs that follow. I’ve set up the band1Frequency pretty much the same manner, and the values just before the setValueNotifyingHost look good but they won’t communicate with the treestate so I’m stumped.

Band 1 is the band I am testing this logic on and it starts at the default of 300 but jumps to the maximum of 20000 when mouseDrag is called, and it doesn’t update parametersChanged in the EqProcessor.cpp. I’m assuming it jumps because it’s not initialized properly but as I said, I’ve tried to set it up the same as the gain but it behaves differently.

I’m not sure what I’m doing wrong, would love to hear some ideas… feel free to look at the project and thanks for any help.

EqTest_1.zip (31.8 KB)

[Mrugalla]

this is the drag behaviour of an eq pad knot, right? make sure to start a gesture in mouseDown and end the gesture in mouseUp as well as making sure that mouseWheel doesn’t start and stop a gesture while a drag currently occurs

edit: unless mouseWheel refers to a different parameter than the xy-drags, which is likely tbh

[reuk]

The argument to setValueNotifyingHost should be a normalised float in the range 0-1.

You can use RangedAudioParameter::convertTo0to1 to convert the non-normalised value to a normalised value that can then be passed to setValueNotifyingHost.

[Stevezee]

Thanks guys, I implemented both and now it works perfectly. The only thing I will say is that I wish the curves were a little more responsive… there’s a bit of lag.

I guess I could limit how often they are updated?

[daniel]

When drawing there is a lot where you can accidentally burn time. But it is a good idea to not draw too often.

1. When you fill a path from a loop, make sure to call preallocateSpace() beforehand, otherwise the internal data structure has to grow often, which is expensive
2. Keep the path from the previous run, maybe even filled when the coefficients didn’t change
   This gets around issue 1 as well
3. Don’t calculate more points in the path than pixels
4. DBG statements slow down as well. Only judge release builds and get rid of DBG once you fixed your issue
5. Use a profiler

[Mrugalla]

A bit of lag is to be expected in all JUCE animations that aren’t boosted by some advanced OpenGL implementation. Doesn’t even need to be a fancy EQPad to make it lag. It happens all the time for no performance reasons.

edit: also i had to edit my initial reply because i forgot eq knots usually have a special kind of mousewheel control

[Stevezee]

I figured out how to activate opengl and it’s super smooth now, really cool. I also figured out how to implement the middle mouse wheel Q control, you can see it in the clip below.

Now I’m having trouble with my custom sliders disappearing in Reaper and Ableton but they appear fine in Plugin Doctor so I’m confused. They are binary data images that I am initializing as a shared resource to limit loading the same image many times in different classes. Not sure what’s going on, like I said I’m new to Juce.

Plugin Doctor and PluginAudioHost:

Reaper/Ableton:

[Stevezee]

I figured it out… I was experimenting with a part of my code earlier so I commented a bunch of stuff out and my images came back.