Feature request: pass a state to be loaded when instantiating plugin
Our plugin has some non-parameter state that assigns the declared parameters to real audio parameters. At its default state, no assignments are set up, so there is really no point testing anything, making pluginval useless for us.
We'd really like to use your tool! It would be awesome to have a CLI option to load a blob as the initial state of the plugin. Thanks in advance for your consideration :)
Interesting. I could maybe add an option to do that but bit seems a bit niche... Part of the power of pluginval is that it runs tests in a random order to avoid "magic paths" like this.
Are you not able to load a valid state by default? Or could you use an environment variable for a path to a state to load upon construction of the plugin? That would probably be more useful than having pluginval load some state at specific points in the tests.
For a bit of context, our plugin is one of these "shells" that allow you to load modules, and then link some generic parameters to the modules' parameters. When you first load the plugin it has no modules loaded, thus the need for loading a state with some modules in (and why a "valid" state by default is off the table).
Another use case I can think of is MIDI parameter assignment, which are also typically stored in non-parameter state, therefore not checked in pluginval today.
An environment variable to load the state is an interesting solution I hadn't thought of (with the downside that we'd need support for this in the main build). Will consider it, thanks!
An (pretty ugly) workaround would be to add a dummy parameter. On change, you could check if the host is pluginval and perform a custom action like loading a specific non-parameter state.
@moritzsur this seems pretty invasive. Actually the environment variable trick did the job and incurs quite minimal changes. Good way to pass info through a host without asking it to :)