[SOLVED] setStateInformation/getStateInformation not being called in a StandAlone Plugin

standalone

#1

I have a plugin that remembers state absolutely fine from within a host (AU or VST2/3), however for some people it seems that setStateInformation and getStateInformation are not being called from the StandAlone version of the plugin.

It works absolutely fine for me on 3 different computers running 3 different versions of macOS, but for my colleagues (both running 10.13.6, but that is one of the versions I tested with) the StandAlone is not remembering state.

Has anyone come across this before? I’m completely at a loss on why this might be occurring, and the fact that I can’t reproduce the problem makes it nigh-on impossible to debug.


#2

This is, where the state is stored:

Maybe those users don’t have access to that folders, or they test on a guest account, where the data is wiped on logout?


#3

I was hoping that it was something as stupid as file permissions, but they have access to that folder (storing a SQLite DB there and that is fine), and had them send me output of ls -l for that folder and all was correct.

I’m just fishing for help on the off chance someone else came across this before, but looks like going to have to keep doing what I’m doing at the moment which is adding more and more file logging where possible and sending them builds to test. But it’s a sloooow process :smiley:

They do have a .settings file, but it misses the filterState section of the XML.


#4

Ah, could have been so easy… :wink:
The only other idea I have, maybe some weird sandboxing?
Good luck!


#5

I think there is some issue on macOs in the standalone wrapper where it won’t store the state depending on if the application is quit either by clicking the window close button or by using the quit command. (From the main menu or the keyboard command.)


#6

Just tested and this definitely happens for me too (macOS 10.13.6), it only actually saves my state if I hit the close button on the window


#7

Bingo! This at least allows me to get the same behaviour and try to fix it. Thanks. :smiley:


#8
        void systemRequestedQuit() override
        {
            mainWindow->pluginHolder->savePluginState();

Fixes the problem. Surely this can’t be an intentional omission? Why would there be different behaviour based on method of quitting? If it is intentional I think a comment in SystemRequestedQuit() that is your responsibility to save state would be helpful.


#9

No I don’t think that was intentional. I’ll take a look, thanks!


#10

I find this choice odd… when I Quit a Standalone plug-in it saves all the settings… so the next time I open the plug-in (Standalone) it opens with the recalled settings and not the default settings.

Just seems odd to me.

Rail


#11

You can choose not to do anything with the state with a JUCEApplication::isStandalone() conditional, easier than having to work out state retrieval yourself in a stand alone.


#12

I had a typo… I’m talking about when you Quit… it saves the state and when you start again it loads the last state by default… That seems odd to me.

Rail


#13

Sure it can save the state, but then when it comes to loading the state in setStateInformation you can choose to ignore the information like this

setStateInformation (const void* data, int sizeInBytes)
{
    if ( !JUCEApplication::isStandalone() )
    {
        ScopedPointer<XmlElement> xmlState (getXmlFromBinary (data, sizeInBytes));
        if (xmlState != nullptr)
            if (xmlState->hasTagName(apvts.state.getType()))
                apvts.state = ValueTree::fromXml (*xmlState);
    }
}

like this your standalone would start every time with the defaults, but your plugins would reload the state they were saved with.
There are situations where you would like the standalone to re-open in the same way as you left it, and if this wasn’t provided OOTB it would require a lot more work than a simple conditional.


#14

Well I wouldn’t add that since that would disable setStateInformation() completely for Standalone… My point is that a Quit shouldn’t save the state (UI position, size, etc… yes… but not the state)

When you start up an App or Plug-in… unless there’s a preference to say “Load last settings on startup”… it should always start up with default settings… which is why I find this an odd decision.

Rail


#15

The .settings file for standalone plugin saves the UI position for you separately from the plugin state.

<?xml version="1.0" encoding="UTF-8"?>

<PROPERTIES>
  <VALUE name="filterState" val="<base64 stuff>"/>
  <VALUE name="windowX" val="263"/>
  <VALUE name="windowY" val="82"/>
  <VALUE name="audioSetup">
    <DEVICESETUP deviceType="CoreAudio" audioOutputDeviceName="Fireface 400 (1ED)"
                 audioInputDeviceName="Microsoft&#174; LifeCam HD-3000" audioDeviceRate="44100.0">
      <MIDIINPUT name="MPK mini"/>
      <MIDIINPUT name="iConnectMIDI2+ DIN 1"/>
    </DEVICESETUP>
  </VALUE>
  <VALUE name="shouldMuteInput" val="1"/>
</PROPERTIES>

And there is nothing stopping you selectively loading state depending on stand alone or hosted plugin. The point being is that it is much easier than having to implement state saving in standalone yourself, so I think it was a very good decision on the part of JUCE to implement it that way.

it should always start up with default settings

“Always” is a bit of a stretch, just because you think that, doesn’t mean everyone does :wink:


#16

I’m up for a poll…

  • A plug-in should always open with it’s default settings unless the host has an option to recall a default setting
  • A plug-in should always open with it’s last parameters recalled

0 voters

IMNSHO Every plug-in should have it’s own Preset saving and recall… but if it doesn’t it’s up to the host to offer that (as I’ve done in my plug-in which hosts other plug-ins). The Host in this instance is the Standalone host which doesn’t supply that functionality by default, but if that’s what you would prefer for your Standalone plug-in then I’d recommend adding that as an option in your custom Standalone code. It certainly shouldn’t be the JUCE default behaviour.

Rail


#17

A plug-in should always open with it’s default settings unless the host has an option to recall a default setting

That’s just silly though; when the “host” is not the standalone wrapper you will always want it to restore the last parameters you left it with, recalling default settings would be insane. When the plugin is a standalone then you can choose what to do in that situation. Why is it so difficult to understand that implementing conditional loading of state in a standalone is much easier than implementing state storage in the standalone wrapper.

In the end I think it’s best if we agree to disagree. :smiley:

edit : I think the wording of your poll is loaded, a question that is actually about the issue being debated would be “Should the standalone plugin wrapper remember its last state when starting again? Yes / No”.


#18

Can you cite a single shipping plug-in which when you instantiate it, it opens with it’s last used settings?

I’m not talking about after you instantiate and open and close the editor… I’m talking about when you instantiate a plug-in, then de-instantiate it and then re-instantiate it. Cite a single plug-in which opens with it’s last parameter settings (unless the host or the plug-in itself has an option to load using a default preset).

Rail


#19

No further comments.