New FlowStone Preset Manager

[pwesynthmaker]

New FlowStone Preset Manager

This modified version of the Preset Manager has an additional
text entry box (white box) for assigning the total number of presets.
Font size is increased for easier viewing.
Layout is rearranged and easy to modify.

Download includes the schematic file presetmgrefx.fsm and
the toolbox mod presetmgrefx.hom

Download Link:
https://www.inventfx.com/_inventfxfstone/presetmgr.zip

==========

Image Preview Preset LED Button Switch Primitives:
https://www.inventfx.com/_inventfxfston ... tledsw.jpg

Image Preview Preset Manager:
https://www.inventfx.com/_inventfxfston ... mgrefx.jpg

==========

[Spogg]

Interesting idea to give the user the option of extending the number of presets.

Is the input box limited to 128 which I understand is the limit for VST specification?

Also how does it work in a plugin? The number of presets available is baked into the VST plugin, so changing it at the user level won’t change the VST. Also would the new increased number be saved with the DAW song?

[pwesynthmaker]

Thanx for the input Spogg ...
I am going to eventually experiment with putting a limitation on the number of presets that the 'white box' can accept ... a simple 'bool less than >128' (boolean) algorithm should do the trick! Anyone who would care to assist is more than welcome.
My main purpose was to be able to actually access the preset quantity factor. It was previously necessary to open numerous mods within mods to locate the 'total box' so one could at least have more than the hard-wired code 1/1 default listing. I am fairly certain that the limitation is 128 maximum as you mentioned. This is and has been the standard for a great deal of time.
The following is for 'newbies' ... Spogg, Trogg, MV, BobF, Tulamide and Even Maik the Man Himself and others might like it as a 'refresher to what they already know!'
The preset manager automatically identifies the number of 'properties' prims as soon as it is placed in a FlowStone Schematic. Any mods with the 'p' pin link automatically upon its inclusion. Adding and/or removing mods that are assignable to preset control is acceptable within certain limitations.
The main 'File' button drop down list commands of 'save/load/save all and load all' are subject to the mods/controls compatibility to send/receive.
Preset management is primarily through 'wireless p pin' interconnects.
Some controls have prims that are not preset manager recognizable or if they are, will send but not receive control changes. An example is the SFZ sampler. It does have a 'p' pin embedded in the 'load' mod that will send information but not retrieve and reload an actual SFZ due to the nature of SFZ text file protocol. At present it simply does not contain File Read/Write for an actual soundfont because it must 'callup' a WAV file for MIDI processing. Each time a preset is saved for the given schematic if it contains one or more samplers they send file path information that is repetitive such as: "C\Program Files\myfileagain.sfzC\Program Files\myfileagain.sfzC\Program Files\myfileagain.sfzC\Program Files\myfileagain.sfz ... until it maxes out usually at 255 characters ... which, of course disables everything! I believe what happens is the FlowStone Ruby Assembler tries to avert a 'Nyquist Truncation Overload' and might be why all of a sudden the entire schematic, program and computer hit a proverbial 'binary brick wall' and ... CRASH!
Then ... ? reboot ... delete the project because it just won't even fire up to fix it and ... well everyone knows. Usually by the time this happens your cerebral cortex is just too packed with code and connections to even remember what started out as a brilliant vst and ended up as a 'Very Stupid Trial and Error' workout.

So ... I found out that one could allow other mods controls such as knobs, sliders values and similar to work properly by simply 'clicking' on the 'SFZ p pin' and renaming it (such as N/A) so that is still connected but 'preset manager non-operational' to solve this.

I am going to post this much ... Spogg and start an additional reply post so as to try to not frustrate the courageous newbies and diehards (:

[pwesynthmaker]

Continue onward in the mysterious preset manager sanctum ...

Yes ... if one adds additional presets to a schematic after initial build while still in Flowstone they will be added into the program.txt file as well as additional mods controls too although once 'out of the box' and exported into the real computer DAW world it is most likely the DAW that will control the load/save addon capabilities. One can add presets to the vst through the DAW's preset management system and then add an additional preset 'Program (*) Number to the vst and then use the vst preset manager and possibly load/save it, but usually ... not vice versa. This is also true while operating with a preset manager in Flowstone. It is the 'Host Command Priority over VST Recipient' that determines preset manager send/receive allowance.

An example of adding and manipulating the preset manager in a FlowStone Schematic Project:

Add a preset capable mod such as the 'Amp' Mod ... 'Modulize It' ... Add Audio In/Out to the mod (blue pins) then MIDI (red pins) Input/Output ...
NOW ... the amp is FLowStone Exportable as both a standalone 'executable' and/or vst/vsti 'plugin ...
Add the 'Preset Manager' ... adjust the amp volume to ... something like about 1/3 ... 'click' on the 'Name' button to rename the preset if desired (optional) ... then ... 'click' on the file button and 'save' the preset (.txt) text file as 'Program 1' (unless it has been renamed, of course) to a suitable location ... preferably within the same folder as the project. I suggest creating a new project folder to save the schematic in and the subsequent .exe and/or vst/vsti exports and the preset manager text file(s). This ensures that the preset manager has a good, solid 'send/receive capability' to the project files.
Continuing ... now adjust the amp knob again ... back and forth a few times (this will make certain the preset manager is 'awake and responding') and then set it for ... ooh ... about half way up and save the second preset ... as a separate text file (or it will overwrite the first one) in similar manner as the first. Repeat this process one more time with the volume at about 75% ... Now ... test the three presets and it can be seen that each time a preset is selected the knob will be 'wirelessly' adjusted to the value set ... Neato! Now ... press the 'File' Button one more time and use the 'Save All Programs' option to save a separate text file of the three combined presets.

Monolith Footnote: Once a project has had a preset manager added and altered the preset control value parameters are permanently embedded into the project. Deleting the preset manager will not delete the preset manager control values that are already saved ... even if the schematic/project is renamed and moved to another folder/directory.
This is a proprietary function that is activated upon the system utilizing the preset manager ('p') pin capabilities. It is intended as a useful feature so that preset function can be attained when a project becomes an exported vst. Without this 'Home Away From Home Firewall P Pin Feature' there simply wouldn't exist a reliable preset manager ... so be careful about installing, editing and saving presets.
How to 'overide' the preset saved information in a schematic File:
Open any/all mods that have been control value embedded and have the 'p' pin connected to them ... Simply rename the pin(s) ... then delete the preset manager from the project ... rename the project mod, and schematic and any 'Properties' boxes (these are little mods that weave the preset manager into a project) involved inside mods and controls and then ... move/save it to another location.

[Duckett]

I've been working on a delay recently, and the Edit Box features heavily in it, as I know from my own experience on the user side of things how frustrating it can be to need/want a precise value, and having no way of entering it... probably below "host tempo sync" on the Great List of Most-Requested Features, but certainly something users care about.

All this to say, it pays to make sure you can't pass values that will crash/freeze your plugin- just because it's possible to enter ridiculous numbers for values doesn't mean it's a good idea... just like a large percentage of cooking is prep, a large part of plugin development is doing the best possible job of idiot-proofing one can, before setting a plugin free.

Also, preset management, or really any "save/load" aspect of FS (or plugins in general), has been one of the very few areas where I have found myself wishing for a native data format, rather than the generic ".txt" etc. file types.. at the very least, had I the ability, I'd have a plugin default to using its name plus the current date and time for "save new", and also default to the save location being a "user presets" folder in the plugin's folder. Not to remove the ability to name or save what/wherever if the user so chooses- but if the user is lazy/sloppy like me, there can soon be too many files that are badly named and not in the right place ("Hmm, wonder what synth I made AmazingWooshPad.fxp for in 2012, that somehow ended up in my desktop folder?")

[Spogg]

... I believe what happens is the FlowStone Ruby Assembler...

Just to politely clarify something here: There is no “Ruby Assembler” in FS. Ruby is interpreted in real time by FS and isn’t compiled.
As I understand it, all the Prims are coded in C++ (I might be wrong, but it’s certainly not Ruby!).

When you save a knob into your toolbox, or re-use a knob from another module in a previous synth, the previous preset parameters for that knob are still saved in the preset parameter prim’s code. The Preset manager prim stores a list of preset names alongside a corresponding index value. When you change a preset the manager just sends out the index number to all the prims with an active P connector. So it says “Hey guys, you all need to pick preset number 17 now”. AFAIK the preset parameter module in the knob doesn’t need to tell the Manager that the value stored for that preset number has changed, until the Manager is asked to save a preset, at which point he needs the information to put in the text file. Likewise when you load a preset or bank the Manager distributes the new parameter values based on the parameter names in the text file.

If you change a knob’s setting, when you save the schematic but not the preset, the knob’s setting is saved as a snapshot in the schematic, even though the preset manager isn’t aware of the change.
When you change a knob’s value, providing Lock is not set, then change the preset to another one and back, the knob will use the value corresponding to your last change, even though the Preset manager hasn’t been informed. The Manager will just send out the preset index number.

In FS 3.xx there’s no way to clear out any previous values stored in the preset parameter prims, so each indexed preset slot has to be overwritten with new data. This means it’s a good idea to make sure that any unused presets available to the user have sensible values stored. In my case I fill them with INIT settings and this avoids unexpected and possible “illegal” settings to be called up from previous projects.

That’s all conjecture as to what the background process is, based on what I’ve come to understand over the years. I’m very happy to be corrected on anything.

[pwesynthmaker]

Bless You Spogg! I know so little about the politically correct computer terms to use.
Getting that preset manager proverbial "hidden-pandora-white-text-box" out into the open to be able to freely modify the number of presets was like trying to remove a chinese finger puzzle super-glued to a scorpion and a praying mantis and put it back on a 3-toed sloth and a porpoise.
MyCo must have put it where it originally was intentionally to prevent us from attempting a promethean white cliffs of dover "I wonder if I need a parachute? ...NAW!" experience.
So ... like our Vulcan Moderator and many others will advise to newbies ...
USE AT YOUR OWN DISCRETION OF RISK.

I keep all my original toolbox *.homs in separate isolated directory folders (one for the system mods and one for the user mods) and each time I modify something that may be preset manager accessible I rename it and add it to the user toolbox box first and then overwrite them with the original backups as needed. "INIT Settings" command is a miracle worker.
I probably should fill the entire 128 slots with it first.

That's like 'smokin in the boys room' \\ write i28 times on the chalkboard ... I will not smoke in the boys room ... I will not smoke in the boys room ,,, I will not smoke in the ---
All of a sudden you hear?
PSST! Hey guy on the chalkboard ... it's 3:45 P.M. ... we got doobies in the boys room ... let's GO!