How are people saving a plug-in's size?


Hello, I am now running the recent ‘develop’ version because of VST3 resizing fixes.

Unfortunately it appears the editor’s constructor is called before the setStateInformation.
Therefore the resize() call is wiping over the saved starting value. I can’t do this as an example…

		if (isVisible() && bOpened)
			processor.uiSizeY = area.getHeight();

…Becuase the visible state is now set early.

Is there a way of saving the current size and restoring that size when the plug-in reopens?


There is a caveat, when you set the ResizeLimits, the minimum size is applied, overwriting your saved size. It works if I get the saved size BEFORE I apply the resize limits, in my editor constructor:

    auto size = processor.getSavedSize();
    setResizable (true, true);
    setResizeLimits (800, 450, 2990, 1800);
    setSize (size.x, size.y);

In resized():

processor.setSavedSize ({ getWidth(), getHeight() });

And in the Processor:

void MyAudioProcessor::getStateInformation (MemoryBlock& destData)
    auto editor = state.state.getOrCreateChildWithName ("editor", nullptr);
    editor.setProperty ("size-x", editorSize.x, nullptr);
    editor.setProperty ("size-y", editorSize.y, nullptr);

    MemoryOutputStream stream(destData, false);
    state.state.writeToStream (stream);

void MyAudioProcessor::setStateInformation (const void* data, int sizeInBytes)
    ValueTree tree = ValueTree::readFromData (data, sizeInBytes);
    if (tree.isValid()) {
        state.state = tree;
        auto editor = state.state.getChildWithName ("editor");
        if (editor.isValid())
            editorSize.setX (editor.getProperty ("size-x", 900));
            editorSize.setY (editor.getProperty ("size-y", 500));
            if (auto* activeEditor = getActiveEditor())
                activeEditor->setSize (editorSize.x, editorSize.y);

Point<int> MyAudioProcessor::getSavedSize() const
    return editorSize;

void MyAudioProcessor::setSavedSize (const Point<int>& size)
    editorSize = size;

Hope that helps


My debug prints don’t verify, that the editor is constructed before the setStateInformation, I would claim it is a red herring. It was just the case, if setResizeLimits is called, it will resize with the minimum size due to this code:

If no size was set before, it will set to minimum size, constraining a size of 0/0.

So actually to add to my previous post, it works even better just to call the setSize before the constrainer:

auto size = processor.getSavedSize();
setResizable (true, true);
setSize (size.x, size.y);
setResizeLimits (800, 450, 2990, 1800);


Thanks, I will try and copy what you’ve said.
I’ve just checked again and the editor constructor IS called before the setStateInformation is called. This is the case in FL Studio with VST3 anyway.


Thanks for the feedback. I tested in Logic, so seems that FL Studio behaves different.

If you have still problems, maybe try to output in your test the address of the instance (or what I do sometimes is adding a Uuid as a member), just to be sure that it is really the editor of that instance. Some hosts create test instances for the plugin and editor to do some checks for whatever reason (like opening the editor twice and similar, that was reported here on the forum).


In VST3 the constructor is called before setStateInformation - with VST2 the constructor is called after, and as you confirmed with Logic, so is AU.
I’m just about to roll back to 5.3.2, to test how it used to be…


I doubt it is related to the juce wrapper, but rather how the host implements the different plugin formats.
So I take it the code I suggested doesn’t solve your problem?
There would also be the option to have a flag to identify, if the state was loaded before, and only in that case you would apply the size. But that is really hacky…

Anyway, I am curious what you will find out



                activeEditor->setSize (editorSize.x, editorSize.y);

…Seems to work fine, thanks man, I guess it’s OK to access the editor from there, as it’s not the actual audio thread? I didn’t even know I had access to it TBH.


Yes, since you are checking if it is not nullptr. One should assume that destruction of the editor happens from the message thread. So yes, if you call that, ensure you are on the message thread as well (usually the case for setStateInformation, I don’t know about guarantees though).

An exception I can remember is FinalCut, which has multiple background instances to render the waveform. In this case all happens from one thread, which is not the message thread. But then there is never an editor involved, so it should be safe as well…


Excellent info! :smiley:


There is at least one host that calls (set/get)StateInformation from a different thread, though I forget which.


AAX (unless you use the AAX_eProperty_RequiresChunkCallsOnMainThread flag)



Ooh, that’s interesting. How do I set that?


Well it may be deprecated in the future… but if you want to use it you can add this to your copy of juce_AAX_wrapper.cpp in createDescriptor()

       #if JucePlugin_AAXDisableDynamicProcessing
        properties->AddProperty (AAX_eProperty_Constraint_AlwaysProcess, true);

       #if JucePlugin_AAXDisableSaveRestore
        properties->AddProperty (AAX_eProperty_SupportsSaveRestore, false);
        ///////////////// Added by Rail Jon Rogut
        properties->AddProperty (AAX_eProperty_RequiresChunkCallsOnMainThread, true);

        if (fullLayout.getChannelSet (true, 1) == AudioChannelSet::mono())
            check (desc.AddSideChainIn (JUCEAlgorithmIDs::sideChainBuffers));
            properties->AddProperty (AAX_eProperty_SupportsSideChainInput, true);



Thanks for the code, but AAX_eProperty_RequiresChunkCallsOnMainThread is already set to true in my ‘develop’ branch…


You must have modified your local copy, the JUCE develop branch doesn’t have that.



Oh you’re quite right I had already tried it, I’m sorry.
Has anyone tried VST 2 scaling, with the develop branch? Mine is totally screwed now (yes, this is a clean clone with no local changes)
edit I’ve now gone back to the 5.3.2 zip download of Juce. The above fixes still work for me.


What issues are you running into specifically? I’ve got a few fixes for the Windows scaling that should be on the develop branch soon but it’d be useful if you could send over examples of the issues you’re having.


OK, I just discovered that you need to test Windows scaling again. Right click desktop/ Display Settings / ‘Scale and layout’ / ‘Change the size of text, app and other items’ to 150% - then you’ll see it. I’ll send an example of just background graphic going wrong in a minute or so. Where is the best place to post it?


Feel free to send me a PM or start a new topic as this one’s been hijacked a bit.