Parameter Automation - Updating UI and recalculations


#1

HI. I apology in advanced for my lack of knowledge or if this has been discussed before!

I have a simple plug-in with one parameter and a slider.
I initialize the slider on startup with parameter->get() and when a slider changed i set the parameter inside ‘sliderValueChanged (Slider* s)’. So far so good.
But the only problem is when the parameter is being automated by the host. I had to somehow update the slider to show the changes that’s being made.

My first attempt was to use AudioProcessorListener Class and use it when the parameter is not being changed by dragging the slider directly.
Results from ‘audioProcessorParameterChanged’ was unsuccessful because apparently it didn’t updated continuously. It only worked when i moved play position.
So i decided to add a timer in my AudioProcessor, and combine it with AudioProcessorListener which told me when something was happening. I also had to add a timer in ProcessorEditor to check if the update flag is up and so update the slider.

Things seemed to be working while automating (FL Studio), except when i moved the seek bar (song position) the parameter and slider kept resetting to a certain value, and ignoring the value i was dragging to (I think this was happening without any automation).
I’m not sure when i use ‘Slider->setValue()’ in the timercallback, if ‘sliderValueChanged (Slider* s)’ is getting called… and creating a loop.
I use a flag, when ‘sliderDragStarted’ i set it to true, and false with ‘sliderDragEnded’. This way with ‘audioProcessorParameterChanged’ i know if the parameter change is coming from slider or not, and so i wont update the slider inside timercallback.

Anyways i haven’t solved it yet. It seemed a lot of work to handle this. I know there are some advanced ways to connect and communicate between processor and editor objects, but my C++ is not that good yet.

Isn’t there a way to tell if the host is changing a parameter or automating or something like that?
Do we have to use a timer to catch these changes and update the UI and recalculate stuff?

How do you deal with this?


#2

The AudioProcessorListener is a little unfortunate. I also tried that one when starting with juce. But it turns out, that it is now only meant to communicate to the host (i.e. the host is the only listener for the processor).

Because the drawing needs to be separate from processor calls (especially the audio thread), the approach to add a timer has many advantages.

Another method is, if you have your parameters in an AudioProcessorValueTreeState, the most convenient is to create an AudioProcessorValueTreeState::SliderAttachment, which does all synchronising for you.

Addition: The “by hand method” is covered in this tutorial - audio parameter


#3

It seems i better move to AudioProcessorValueTreeState and avoid all of this.
The AudioProcessorValueTreeState tutorial was cool, hadn’t seen it before. It would be nice to receive an email when new tutorial is added.
I couldn’t build that project with visual studio 2010 out of the box and I use JUCE 4.2.1.
Some undefined AudioProcessorValueTreeState errors. Whats happening? Do i have to upgrade to a more recent version of visual studio to resolve this?


#4

Hi erteash,

The AudioProcessorValueTreeState class itself requires a compiler that supports C++11 lambdas. Maybe that is the reason?

Best,
Martin

BTW I think there were some emails around the 5th October when this batch of tutorials was released…


#5

The original problem is probably that the host sends an automation value to your plugin. Your plugin reacts, and sets the slider accordingly. When the slider is set, it triggers a notification back to the host, creating a feedback loop. Most hosts immediately disable any following automation (as they think the user is ‘writing’ or temporarily modifying automation), but really anything can happen - especially if you use async updates, which is default.

To solve this problem, you must ensure that any changes read from the host (ie. in your timer) must is applied to your slider using juce::DontSendNotification, such that no client<->host feedback loop exist.

I believe the SliderAttachment class solves this problem for you, automagically.


#6

After installing Visual Studio 2015 i can now use ‘AudioProcessorValueTreeState’. I changed my code and Its much easier this way, and so far everything looks OK.
Except when automating the parameter in host (FL 11), the slider doesn’t move while playing back. It only updates when moving the song position .
Is this expected? Do we have to check and set the slider value with timer?

Update: This is not happening with FL 12! The slider moves very nicely!
Is this Hosts fault or JUCEs?


#7

Well if it’s not working then it’s probably a combination - FL 11 is doing/expecting something weird and JUCE doesn’t have the required workarounds. I’ll investigate.


#8

I noticed that in FL 11, the slider moves a bit with Asio driver selected, but still it gets stuck after few bars. It doesn’t move at all with primary sound driver. Maybe FL in previous version was reducing redraw rate or something with non Asio drivers. I don’t know how things work, i just thought to report it.


#9

I was trying to use a TextButton instead of ToggleButton with ButtonAttachment and it didn’t work. Is this intentional?


#10

It should work but you’ll need to use your TextButton in a togglable way.