General Preset Manager question.

[RJHollins]

Hello everyone,

With only a short time using SM, and since migrating to FS, I've dipped my toe into the programming of my first project. All beta test reports have been positive on this first project [happy to say], as the 'core' of this project is designed to be a sort of template for the next in a series.

As I slowly gain a better understanding, I'm also contemplating ways to improve or expand on this program concept. Which brings me to the 'Preset Manager' question.

To be quite honest, I've not utilize [nor really implemented] the PSManager beyond it basic inclusion into my VST project, thereby making identified parameters available in the Host. I have relied on an independent TEXT file to store specific user input [basically MIDI patch numbers], as a single configuration.

Thinking forward, I'm looking to see if the PSM could be of much more use.

Here's the [example] premise.

Say I've put together a vst EQ ... basic 3 controls include Frequency, Gain, and 'Q'.

Now ... would like to transform the VST into a proper 'stand alone' version.

Can the PSM in any way be utilized to load presets that would
1. recall knob position & settings ?

2. load presets that would alter base functions such as choice of frequencies.

3. allow a type of 'skin' change of the app ?

Maybe not the best example to use, but I'm trying to understand if the PSM would be a key primitive that I should be looking to employ.

Appreciate any insights, links, examples that could help me get a good start on this.

Thanks again!

[Nubeat7]

every parameter which have a PresetParameter primitive connected is stored in presets as long the preset bool is set to true, and you are using a PSManager, just take care to use unique parameternames.

[RJHollins]

Hi NuBeat ...

Ah yes ... I checked a save preset file from the PMngr, as all the parameters with values are there.

Very nice

Thanks!

[RJHollins]

Activating an older posting here .... on to new questions

Out of curiosity ...

I've been using the 'PreSet Manager' in a very basic task up to this point. I now wonder if I'm creating more work for my programming by not using the PM for things like this:

In my program, I have several ARRAYs that contain patch numbers and names that are used to send MIDI PRGCHG messages. [Particularly the numbers]. The corresponding Names are used in the VST GUI for display purposes.

I have these ARRAYs setup as User Defined, User Editable.

Currently, I've been assembling all these Arrays into a single TEXT file that AutoLoads.

The question is ... am I making extra work ? Can the PreSet Manger [somehow] be employed to include, and handle/manage all of these User defined values ???

I know a lot has been written about the PM, along with the SM/ FS manuals ... but in my continued reading, I'm still not understanding if there is a better way

Thanks for any insights on such a mundane, yet vital aspect.

Sincerely ... Thanks !!

[TrojakEW]

In step LFO you have option to define and save user settings. Maybe you can try this instead of autoload from extranal file.

[billv]

'Preset Manager'

I have been working on the pre set system(finally) for my synth, over the last few weeks.
I found your comments really interseting here RJ.
Seeing as were both working at similar issues..I thought it might help to hear another perspective.

My problem is the behavior of the Pre set manager. Its the save/load file dialogs I hate.
I've always wanted a system where this is done automatically, so the user just has to
1.Rename the preset(if required)
2. Press save.
Thats it. Preset there next time synth is loaded. No external file saving/loading by the user.

I kept failing at modifying the Preset manager Module for what i want. So I've bypassed it.
I've started from scratch instead, and brought in the preset manager "Component"and set it up.
Then in every control, set "store in prests to false".
So the controls can now be automated in a host. First step done.
Like yourself, for the values, I've opted for the "independent text file set up".
I'm looking at about a dozen files....I'm saving things into sections. This will create
a sub preset system within the global one, allowing the user to mix presets together, quickly form
new ones. or subtle variations.
Working great so far...but its a big job....and like yourself, I'm still nutting out some
finer points.
Hope this helps in some way.
have built a few "datasavers"...still working on them...but if want a look..let
me know and I'll upload what I'm working on....

[Nubeat7]

Currently, I've been assembling all these Arrays into a single TEXT file that AutoLoads.

you can also use the "preset parameter array" primitive for this, dont forget to set the max values (one of the first inputs) to get correct values... if you want to save settings global (outside the preset system) watch this thread viewtopic.php?f=2&t=1548 stw shared a well working example for this

Ps.:watch the ruby stepseq withs random, i posted in this thread viewtopic.php?f=3&t=1595&start=10
to see how the presetparameter array works

[RJHollins]

Hi Billv and NuBeat,

Thanks for checking in on this .... always good to hear from ya !

This need to store various arrays, variables, and other 'text', is an area that I would really like to improve upon ... at least from the current way I've been doing it.

I'll get an example posted to help explain what I've been doing .... but the basics of it are:

1. a BUNCH of ARRAY's .... I [basically] link them all into one big array to save ...

2. come loading time, I take the 'big' and split it back up into the original groups, which then get sent back into the 'User Input configuration' module.

That is the basic idea. I've also started using the BUS create/extract as a variation to manage the various groups.

As to the posted links ...

I have been following those threads for sure ... still learning from all of them.

I guess what I'm seeking was a consolidation of all data storage/retrieval via the 'PreSet Manager', whereby the 'User Data [outside of the schematic data], is tagged onto the saved file much like a 'User DATA' section.

For 'sanity' purposes, it would seem better to keep the User Arrays separated [as each section is in its own module]. Saving everything into one file is neater ... but we would still need to extract the data.

Reading about the 'PreSet Manager' there is mention of how it Saves and then can ReStore settings ... an intelligent system that allows for dynamic changes being made as the project develops.

Not sure what to ask about ... just thinking out loud, hoping for a better way than what I'm doing now.

I know the PM has had much discussion [particularly at the SM forum], and know this is NOT a 'glamorous' topic ... but I hope something so mundane can find an elegant solution

Thanks Guys !!

[tester]

I noticed there are some (expected) issues when dealing with large (string) arrays made for alternate preset management system (made some tests with c.a. 2000 parameters converted that way). Said this - I think within next week I see how this could be solved. There are few major things to pay attention to.

1. Sample and hold prims, to separate sub-circuits from main preset convertersion routine. A lot of them (otherwise backward triggers may kill FS during simple update tasks).

2. More smaller arrays. The bigger single array you have (in terms of flow of triggers in and around) & wish to convert into string and back, the more problematic it may become. The time needed to connect prims in circuits (FS delays) - will tell you how the app may behave.

3. Very rigid trigger order (1 - latch values only when wish to save them, 2 - send pack to conversion, 3 - save the file), reducing amount of triggers, and some (counter based?) verifier to execute certain steps (latching values?) - so that your preset stores all values and waits if something did stuck.

As I said - my first attempt to convert extensive preset system, from single values (2000 per program) into comma separated strings was theoretically successful, but in practice - it showed above mentioned things to consider.

*

Thus, reloading data will require "last" switch for getting value (can be combined either with wireless connector or array with get at prim), and "preset parameter" is used only for automation, not storing anything.

One more thing. My past experience shows, that buses may cause some problems (glitches); if the case refers to green data, I would rather use arrays than buses.

[chackl]

Just a verry General question:

If you put all data into one Parameter (ore more that are fixed) - how would be the automation of it?
Moving one Parameter and sending 2000 ....
This was just the Problem, why i never did any developement here.

But basicaly is there a way to fix this?