Preset per Module or per Schematic

[aronb]

Hi,

I use FlowStone itself for producing directly. I do make VSTs on occasion, however I mostly stream data from my FlowStone Schematic, to Reaper (via Reaper's ASIO driver / pipe), and then in Reaper to the audio driver (MOTU 24Ao in my case).

Using FlowStone like this makes it possible to add modules and/or rewire patches while creating - that way you are not limited to just a VST or group of VSTs in a DAW. You can add gains, or filters, etc. live as you work. Plus this allows you to wire the synth in a different way, producing even more sounds or variations. I find just making VSTs of each module very limiting, especially during the creative process... VSTs are useful, just not ideal in this case.

I was wondering, would be possible to have a Preset for EACH module (just for that one module)?

Or can you only have a Preset Manager that handles ALL presets (only a global type preset per schematic)?

While I am a long time user of FlowStone (and SM), I am a newbie to Presets and the Preset Manager

Thanks,

Aron

[kortezzzz]

Yes, I've already done it. But to do it properly, you should give a unique name to any of your "P" output connectors in every single preset manager instead of leaving them un-named as usually. Moreover, every knob or button that is related to a unique preset manager should also carry it's "P" output's unique name.

[aronb]

Thanks,

Can you please post a simple example? Again I have never done this and would like to learn

P.S. I get unique name of the P connector, but I got lost about each button etc. having it's P output unique name???

Aron

[Spogg]

This question has been raised before and my answer then was only 1 preset manager per plugin, since that’s what it says in the FS component guide. But that’s for plugins running in a DAW and maybe with Aron’s FS setup the rule can be bent, but Kortezzzz says it works in a plugin.

So I would like to ask what happens with preset management in the DAW when you save and re-load a song. Does it recall all the various preset manager’s settings and if so how?

Let’s say I make a drum synth with 8 sound channels and each one has its own preset manager so I can load and save Kick and Snare presets individually. Then I have the “main” preset manager at the top level which I would want for storing “kit” presets. When I recall a song in the DAW or load a kit preset do all the individual sounds get loaded back into the kick and snare channels etc?

@Aron:
Every control that responds to presets will have a preset parameter module with a “P” wireless input. What Kortezzzz is saying is that you add a name to these P connectors to match the name in their own preset Manager’s P name, so they only respond to their own preset manager. So in my example above the Snare preset manager’s P name would be Snare and all the knobs etc in the Snare channel would have their P connector named Snare too.

[kortezzzz]

Try this schematic. Wrote a short explanation at it's top stage.

[kortezzzz]

Let’s say I make a drum synth with 8 sound channels and each one has its own preset manager so I can load and save Kick and Snare presets individually. Then I have the “main” preset manager at the top level which I would want for storing “kit” presets. When I recall a song in the DAW or load a kit preset do all the individual sounds get loaded back into the kick and snare channels etc?

As we know, In the DAW universe we are restricted to the DAW rules which allow using only 1 preset manager. So according to your example, you won't be able to just drop all the PMs to the schematic and make them work, even if they've named uniqully.

Here are the 7 steps I've used to help my plugins avoid of errors:

1) When you start a new schematic, first drop in your main preset manager (the one that you'd like to be recognized by the DAW) in to the top stage. In your example it would be the one that will load "full kits".
2) save your schematic, close it and re-open
3) Add another preset manager, lets say for "kicks" in the lower stage and name it's "P" output with a unique name. Let's say "kicks"
4) Limit the "kicks" preset manager to only 1 single preset and set the "current" input of the PM's textfile primitive to zero (all programs)
5) Set it to load\save text files and determine a different file extension name, let's say " *.kic "
6) Add into it's text file loader a preset module with un-named "P" input which communicates with your main preset manager. This preset module will only save the current kick's name as a string, let's say "kick 1.kic"
7) Whenever the "kick 1.kic" is called, the the file will be loaded

Sure you can make some minor changes in this plan, but this is the best way so far to avoid of errors.

[Spogg]

Very interesting Kortezzzz!

At some point in my life I hope to make a multi-channel drum synth so this idea may actually be useful to me and I can test it.
Presumably the text file for the kick preset will have to include the full path to the preset or a path relative to the plugin’s location. I’m guessing this would have to be updated when a new kick preset is loaded, so the kit preset manager would tell the Kick preset manager to go fetch the right kick preset… Right or wrong?

[kortezzzz]

I’m guessing this would have to be updated when a new kick preset is loaded, so the kit preset manager would tell the Kick preset manager to go fetch the right kick preset… Right or wrong?

Yes. But I used a slightly different approach in my new current development (a new arranger...):

Whenever a new instrument \ sample gets loaded, the preset manager automatically creates a text file with an exact name of the sample and save it into a separate folder called "instruments". For example, if loaded a violin wav. file called "violin.wav", my preset manager instantly creates a text file with the name "violin.ins". Now, every change you gonna make during the time that this sample is loaded (env. knobs, on-off buttons, effect, etc) and then press "save settings", the text file gets saved. Next time you load that sample, you get those saved settings. The only disadvantage of this approach is that the user can create tons of setting files with every sample he loads, but it's very negligible in terms of file size so I don't see any problem with that.