Where are you first updating GUIs?

Hi, I’m curious as to where people are setting up their plugs gui’s on first loading.

For example I’m using ‘sliderValueChanged’ to update waveform selection graphics in a childs’s Image variable, but the function is not called on plug-in initialition, and yes I’m using AudioProcessorValueTreeState for vars.

Where are you doing the GUI init for DSP dependent things like this?
Is there anywhere I can guarantee the processor has been fully loaded when the the GUI is init, in all plug-in types?

I’m currently doing an update on the first paint() call, which works great but it feels a bit bodge like.
I don’t want to use timers, that’s a very loose and scary method.
I’ve either got something in the wrong order or everybody just gets around it somehow, like I do.
Thanks.

AFAIK it is impossible for the editor’s constructor to run before the processor’s constructor has finished running

1 Like

The processor is fully constructed when the editor is created. But there is no guarantee that prepareToPlay has been called, so things like channel-configuration and samplerate are maybe unknown at this point of time, also the stored state/parameters might not be up to date.
The editor just have to deal with it, that this is possible, and should update itself when required.

2 Likes

So I can guarantee the DSP is all setup and setStateInformation has been run BEFORE the GUI elements are even instanced?
On VST3 and 2? Excellent, although I’m sure I’ve seen otherwise at times, perhaps I’m mistaking it with somethig else.
Thanks.

I don’t think you can guarantee setStateInformation has been run. The editor may start with default parameter values, then be updated later.

setState is only used when the plugin was closed at least once, so there must be init values everywhere where you use the apvts’ state. use parameter attachments to attach stuff to parameters in the gui and then use their sendInitialUpdate() method to repaint to the right values on init

1 Like

You could just run setStateInformation yourself in your processor’s constructor…

If your plugin has a preset system, then my suggestion would be:

  • if the user had a preset active the last time the plugin was closed, then reload that one at startup
  • if not, pick a default preset to load

Yeah, I just went for a walk a realised that, before I had to access the editor from setState, because I wanted to save the GUI size in VST3 (this is from a Juce team recommendation).
So I can’t guarantee that setState is called before the editor is setup, at least on VST3.

I just wanted to know how people actually tackled the problem in general.
I wasn’t aware of ‘sendInitialUpdate’, I’ll look into it, thanks.

Hang on, I’m getting confused again. How do I use sendInitialUpdate?
I set up the attachments in my GUI like this

 .h
OwnedArray <AudioProcessorValueTreeState::SliderAttachment> sliderAttachments;
----
 .cpp
sliderAttachments.add(new AudioProcessorValueTreeState::SliderAttachment(*paraTree,	"WaveformB",	parWaveformB)); 

Then how do sendInitialUpdate from the end of all the attachments?
The compiler states that ‘attachment’ is private and can’t be accessed.

You don’t need to do anything. The sendInitialUpdate() is called in the constructor of the attachment.

Originally that was AudioProcessorValueTreeState::SliderAttachment, since juce 6 this is using the SliderParameterAttachment, which is set up here:

That way the slider should show the correct value, regardless if setStateInformation() did already run or is about to run.

1 Like

you can’t savely call the editor from setState because the editor might currently not exist while setState is being called, but you can easily just set all your states from the editor when it gets build because the processor was already successfully constructed before

Thanks for the info Daniel. The knobs are indeed set correctly, but the slider changed function is not called in the gui on first loading and set state, so I can’t update associated panels with the correct data.
I just wondered whether anybody had a set, tried and tested way of initialising various gui panels outside of paint() that works in all hosts and plug-in types.
I think it may depend on which host, and when it calls the state function. I’m testing with FL Studio on Windows.

You can test if it exists though and then do things like change gui size if you’ve saved it in the state. It’s the advice given to me here and it’s works perfectly. It was needed for my VST 3 plugs.

i guess that makes sense. but still sounds a bit unsafe because between that if and the actual statement the editor could stop to exist… except if you know a method to prevent that i don’t know about yet

That’s weird. I followed the flow through the SliderAttachment and looking at the source it seems to call slider.setValue() here with sendNotificationSync:

Can you put a breakpoint there and see if it ends up there?

And another question: are you sure you added the slider listener before creating the SliderAttachment? :wink:

1 Like

[solved]
Did some more tests… OK here is the relevant function call list on boot up. The 0 value is the default, and then the state is set to the correct value 1.66 (1.4 in Live)
I’ve set DGB prints when in the relevant function…
This is from FL Studio.

SliderParameterAttachment::setValue.parOSC0WaveformB Value: 0
Parameter set in setStateInformation: parOSC0WaveformB. Value: 1.66
SliderParameterAttachment::setValue.parOSC0WaveformB Value: 1.66
! sliderValueChanged called. parOSC0WaveformB
! Listener parameterChanged. parOSC0WaveformB. Value: 1.66

This is Ableton Live 10 lite.
.
SliderParameterAttachment::setValue.parOSC0WaveformB Value: 0
Parameter set in setStateInformation: parOSC0WaveformB. Value: 1.4
SliderParameterAttachment::setValue.parOSC0WaveformB Value: 1.4
! sliderValueChanged called. parOSC0WaveformB
! Listener parameterChanged. parOSC0WaveformB. Value: 1.4

  • So the listener updates the DSP waveform correctly, but the sliderChanged is called BEFORE, so it uses the old data.

Note that Cubase doesn’t even call sliderValueChanged without being physically moved by mouse! So for Cubase I’ll make the waveform graphic when it first paints, which is OK to be honest, it’s just a small check.

Lesson for the day: The GUI call-backs always change before the actual DSP. ALWAYS, even when set by a program change.

Seems obvious really. I can get on with some work now - oh look the day is over! :wink:
Thanks for the input everyone.
Sorry for the verbosity, it helps me understand what the F is going on sometimes, I’m just getting back into Juceland again.
Dave.