A bit confused on how FlowStone store/load data

[Nowhk]

That's easy! If I create a FlowStone schematic that elaborate any kind of variables (string/float/float array/ecc), I save it and I reopen it later, I can see that all variables are "stored" inside the schematic.

I mean: if I've somethings like this:

Immagine.png (16.31 KiB) Viewed 17138 times

every time I open the schematic and I link the final [F] to a text module, I always see the same generated values (when I create them, clicking on Trigger linked to the Loop module). i.e. the result is always the same. This means that the data is "stored" to the last connector [F] inside the schematic:

Immagine_2.png (21.79 KiB) Viewed 17138 times

That's fine! Got it. But...

Once I export this schematic to VST from FlowStone, and I open it, I can see the same data (so, it is saved to the plugin as well). The problem is when I change those data inside the VST: they change "live", but when I save the preset and I reopen it, I can see the old data (the ones when I create the VST), not the new ones.

I know I need Preset Manager and use somethigs like Preset String to restore data inside VST, but why starting from schematic it stores data and inside VST I'm not able? Is it correct? I guess it use the same variables addresses inside the code. So once changed, it should save them as well.

So my question are:

1 - why creating VST from FlowStone it automatically save data for the VST, but from the VST itself I'm not able to do it without using Preset prims? (in fact when I create the VST, I've not Preset prims; seems it creates them for me as special gift ). Is it somethings likes "VST can load data that are stored by FlowStone when creating VST, but if you want to save data from VST itself in the future, process the data you want trough a Preset prim"? Why don't do it automatically?
2 - how would you store a [F] (float array) as VST parameter? (I'm generating such a random 1024 float points that define a waveshape, and for every preset I'd like to save the shape).

Thanks for the help!

reload data.fsm

(305 Bytes) Downloaded 841 times

[Nowhk]

Also, a strange things: "Preset Module" is the tool that is appointed to reload previous stored data.
But if I don't set it after a variable that I'd like to save and I open the plugin rendered by FlowStone (which some custom data used in the schematic), those data are reloaded back automatically, even without that module.

Is there a sort of "Default variable scope" generated automatically by FlowStone (once rendering) that automatically load current variables every time I load the VST and a "User-defined variable scope" that will reload (and store) user edits only if I define that Preset Modules?

I do see nothing in the manual...

[Spogg]

My understanding is this:

Arrays are like ROMs and you can only write to the ROM in Flowstone.
The array contents will be stored in the scehmatic but you can copy and paste an array Prim and it will still hold the data in its copied location.
You don't need a preset manager to read from the arrays in an exported VSTi.
The DAW should take care of saving the VST state when you save the project file in the DAW, providing every control has a unique name, otherwise confusion.

If none of the wizards respond to my explanation I shall assume I'm right!

Cheers

Spogg

[Nowhk]

You don't need a preset manager to read from the arrays in an exported VSTi.
The DAW should take care of saving the VST state when you save the project file in the DAW, providing every control has a unique name, otherwise confusion.

Uhm....

But when I load the VST, it is able to "read" these variables, so I guess they have already "unique name", and be managed in some manner to load/use/manipulate data during playing: why not add the feature to save it?

Maybe because these variables are managed internally by the plugin generated code (save/load/use) and the API of VST are not able to access direcetly to those variables? Thus Preset Manager is a sort of workaround to bypass and make communication between VST variables and (private) plugin ones (which in fact will overwrite them)?

Because in fact what happens is that plugin will first load internal variables (at the state of them, when I exported it), than call the Preset Manager modules that will reload data stored by DAW trought the preset when I save it.

Is this the reason?

[Spogg]

I'm not completely sure I follow you and I confess I don't know the VST SDK at all.

What I said above is based on my own experiments but what I do know is that once a VST is created the code within is burned in and not changeable afterwards by the DAW. The system RAM will temporarily hold anything the VST needs for manipulation and the DAW could access this and save it with the song. There will be a dialogue between the VST and its host DAW when it loads as to what parameters can be affected, which is why, as I understand it, the parameters have to have unique names within the VST.
The presets' text files can be however changed, loaded and saved of course and the VST will respond accordingly.

Maybe somone else can offer a better explanation?

Cheers

Spogg

[Spogg]

This might possibly be helpful to you:

There is a Prim that will store float arrays in a preset so can be saved and loaded with the other parameters in any preset txt file.

I've rigged up a simple demo and test in the FSM below. This provides a knob that enables you to fill an array of the size you choose with lots of float values. You can then save and reload them with a preset manager. There are 2 arrays stored in the schematic for you. If you save the preset and look at the txt file all the values are listed.

There is a big problem with the FS Component Reference manual: It doesn't list the Prim correctly. Search for VST Parameter Array in the current manual. This was correctly listed in the Synthmaker component reference but they changed the name in the toolbox for Flowstone. In Flowstone filter for preset parameter and you will find 2 Prims, one for single floats and one for float arrays. Originally in Synthmaker the floats had to lie between 0 and 1 but as you will see, this restriction no longer applies.

Cheers

Spogg

[Nowhk]

I'm not completely sure I follow you and I confess I don't know the VST SDK at all.

I meant...

FlowStone Presets Modules are used as a bridge between plugin and DAW to store data. Since DAW cannot manage data within the plugin, it uses Presets Module to store them, and FlowStone (once linked plugin with Presets) are able to read/write to this "dedicated memory" (preset parameters list, unique name for each parameter) data.

I guess there is two kind of variable scopes: the one created by FlowStone when exporting, and the one managed by Presets (which can be managed by DAW).

Example...

If I store an array of float without Preset Manager and I export the plugin, inside the plugin I can read and manipulate it. But trought the DAW I cannot save.
Thus, Plugin variables scope.

If I link a Preset Module, when I load the plugin it can read/manipulate data within the plugin and (when a Preset module occurs) also from the Presets parameter list. The difference is that DAW now can save the edited Preset parameter list to the preset, storing the state.
Thus, Plugin variable scope + VST variables scope. (note: when exporting with Preset Modules, I think it already create a preset with current data; i.e. the "Default" preset).

It is just that one scope can be also used by the DAW, the other only by the plugin. Or at least: I guess this is the way FlowStone works with presets?

I've rigged up a simple demo and test in the FSM below. This provides a knob that enables you to fill an array of the size you choose with lots of float values. You can then save and reload them with a preset manager. There are 2 arrays stored in the schematic for you. If you save the preset and look at the txt file all the values are listed.

I see: thank you. Anyway I don't see this preset txt file, it's all inside the DLL. Maybe an additional option? Or what do you mean?

Many thanks for the discussion man, it really helps me to get the concept (if I got it )

[Spogg]

The difference is that DAW now can save the edited Preset parameter list to the preset, storing the state.

Anyway I don't see this preset txt file, it's all inside the DLL. Maybe an additional option? Or what do you mean?

Hi Nowhk

You make a couple of points above that I'd like to address:

The DAW cannot write to the preset text file directly. This can only be done from the Preset Manager (if you have one in your exported VSTi). The DAW is able to store the state of the VSTi in the DAW's own proprietry format, like for example newsong.RPP for Reaper. This file will hold the complete state of the song and any plugins used but is NOT a preset. To save or load a preset for a FS plugin you must use the Preset Manager in the plugin. When you load a new preset to the FS plugin and save the song the new settings will be saved but the preset file itself will not be affected. It's important to note that Flowstone doesn't use the FXB/FXP format; it uses it's own text file format for presets.

The text file I mentioned is the saved preset file for the quick example I made. I've saved 2 preset files with the Float Array contents in them and they are in the zip below. Just have a look in Notepad and you'll see all the values.

Also, the Component Reference manual expands on the use of text files for presets.

Cheers

Spogg

[Nowhk]

The DAW cannot write to the preset text file directly. This can only be done from the Preset Manager (if you have one in your exported VSTi). The DAW is able to store the state of the VSTi in the DAW's own proprietry format, like for example newsong.RPP for Reaper. This file will hold the complete state of the song and any plugins used but is NOT a preset.

Uhm, I'm not sure about this. Yes, it won't save the VST preset file directly, but it will be included (as VST parameter list I guess) in the DAW's own proprietry file. Else, if I open FL Studio and I save the .fst preset of my VST with custom parameters, when I reload it I'll lost it. Instead, using FlowStone Preset Module and save the .fst I can reload it without problem. I don't care about preset text file, I just need VST parameters are stored/loaded correctly.

In few words: I think that FlowStone plugin when loading and reach (for example) the Preset Array Parameter module inside the schematic (that of course its not a real "schematic" anymore, just a coded C++ application ) looks at the VST parameter lists: if this list comes from DAW's own proprietry file, FXP or FlowStone's .txt its irrelevant. This will be managed by DAW and VST API on how to get this list.

What do you think?

[Nowhk]

To make the explanation concise: this is how (in my opinion) thinkgs works.
Let say this is my plugin (that use Presets and Preset String prim) and I export it as VST:

Immagine.png (17.31 KiB) Viewed 17099 times

when I now load it inside my DAW (init stage), it will load plugin variables and set for Label #1 and Label #2 the value 30. Since there is not any associated preset parameter value (no preset file source with data; I've not create it yet) the loading ends. I also think that here plugin will in any case create the list of preset parameters in memory, setting the current values; because if I look at the DAW preset list, I can see them with current value).

Now I move the knob to value 60, and I'll see both label updates. In this moment (I'm not on init stage anymore; but in event stage), plugin will also update VST parameter list (exhibit by the Preset Manager module; the single string in this case) to 60.

Than, I save the preset (thanks to DAW proprietary file, for example) and I reload it.

Now FlowStone first load (init) the plugin variables to 30 (so both Label #1 and Label #2 to 30 as before; of course, since I'm at init stage, it won't propagate data to VST parameter list from Preset String module), than invoke VST parameter list to refresh/reflect its value to the plugin (because this time there is a concise list of parameter with a specified value, not as before), and Label #2 become 60 (while Label #1 stay to 30).

Is it more clear? And most important: it this correct more or less?