In V1 I could use fromJson() and toJson() inside the Widget to load/save user data that do not have anything to do with audio processing, e.g. a string displayed on the GUI or the color of the GUI.
Now in V2 I have to use dataFromJson() and dataToJson() inside the Module to load/save this data.
If this data is a number and/or can be packed into a numeric Param, now I add a Param to the module. As a new side effect, this kind of GUI data can now be controlled by Modules like Stoermelder Macro. Is there a way to prevent this?
If this data is a string and/or canāt be packed into a numeric Param, now I use dataFromJson() and dataToJson().
But what Iām worrying about is the lost of logical separation of Moduleās data and Widgetās data, because now in my Module I have data that only makes sense for the widget.
If you donāt want some of your values to act like a param, then donāt make them be params.
It is not uncommon (to me anyway) for the widget and the module to share data. Your case sounds easier than some, and the only communication needed is for some serialized values.
Still you need to be aware that the two will be running on different threads, and you many need to do something to guarantee that there are no bugs arising from that.
Donāt use Params for storing internal data for your Module or ModuleWidget. Params are for knobs, switches, buttons, and float values that users should be able to directly control. Use a Module member variable for internal data.
This is best. What if your Module is loaded headless and then re-serializes? If you persist data in ModuleWidget, then that data is lost. Module should store all data that you want to persist. If youāre familiar with the MVC pattern, Module is the model while ModuleWidget is the view/controller.
I still struggling with this issue, maybe Iām thinking to complicate or somethingā¦
I used the old json methods in ModuleWidget to store/reload data on creating and changing the widget, it worked without any issues.
Now I try to shift this functionality to the module, but I canāt find any proper entry point in the module widget where the json is loaded and I have random crashes do it via the Moduleās methods. (Maybe because of the separated threads)
So my question: What is the standard way to store and load properties for a ModuleWidget? For example I provide the option to show the module in a āusedā look, this could be put on via a menu entry entry and have to be saved and reloaded on creating the module.
Do you want to store plugin-wide settings? Iād use global variables in your plugin.hpp file, a settingsSave() function that is called after changing a setting, and settingsLoad() that is called in init().
When Andrew originally deprecated the moduleWidget methods in v1, I made an effort to move all my widget specific settings to the module. I added member variables to the module and then the widget reads and writes those as it needs to. (Taking care to check that there really is a module).
For an example you can look at the core blanking plate in VCVRack and compare between v1 and v2. It used to save the width using ModuleWidget methods, and in v2 it uses Module methods.
For the global color scheme settings in the SubmarineFree modules; any moduleWidget which changes that setting calls a function in a function within my dll, which sets global values for setting that all the moduleWidgets can look at.
Yeah, I do the same thing. But you really, really must remember that they are on different threads, so āsharing variablesā isnāt trivial. If you want it to work. And you canāt use a mutex, of you will get dropouts.
I think it wasnāt said directly, but by the assumption of implication. The Module has the data. The ModuleWidget can reference the Module if it has such a non-null reference. If the reference is null, the widget must āmake upā suitable presentation data.
