Preset Manager "saved in preset"

[gurulogic]

Maybe a patching question.. But if not I will try here.

Scenario: My workspace uses 256 global presets broken down into 32 banks of 8 presets (One bank per arrangement/song) which is triggered by incoming MIDI program change messages that follow my hardware sequencers.. The workspace has a number of sub patches or VST's in each of which I will need to toggle "saved in preset" on or off depending on the desired recall settings for each of the 8 global presets in each bank. I do not necessarily want a preset load in each sub patch each time the (stored) global preset changes.

As I cannot have one of the global presets simultaneously enable "saved in preset" for a patch or VST and load the preset data for that patch or VST, I have made a clunky workaround that makes for an easy to mess up storing procedure for any preset number I wish to change the sub patch settings for to have them reflected in the global preset.
The obvious first thought is why don't I have a preset managerx8 in each sub patch, but the problem is I would need 32 preset mangersx8 in each sub patch and all of the patching/interface that goes along with that.

Solution: (and this is where maybe it is already implemented but maybe not working, or I am not understanding the intended usage?) The preset manager has a "saved in preset" inlet which as far as I can tell serves no function. Ideally, when enable "saved in preset" for the preset manager would allow storing and recalling of the preset manager and preset content into a parent preset manager. ie: One global preset could recall the entire stored preset data of another preset manager.
In this particular case, we would want to have the sub patch containing the stored preset manager be excluded from the global preset (with exception of the preset manager itself) and have preset duties within that sub patch be inherited exclusively by the sub patch preset manager.

[senso]

whaoo... store a preset manager into a preset will be very dangerous and memory killer.
Actually the preset can't be saved in a preset manager and I'll probably not implement this possibility.
For now I haven't any clear solution for you but I'll think about a selective "store in preset" option.

[gurulogic]

I understand about the the storing a "preset of presets" being very hungry if too many parameters, so yea probably a can of worms and best to leave alone.
I have found solution for the time being to selectively have a sub patch or VST stored or not per each preset (via a very complex arrays manipulation and with each "song" having a dedicted preset manager controlling workspace (and each stored in preset setting), but having a more intuitive method for doing this would be a nice application in many scenarios I think. Nice to only manage one preset manager at a time for a workspace, and have precise control over what is stored and recalled for each preset.

[gurulogic]

To expand on the concept of presets without endlessly spamming the suggestions forum with new topics, something that keeps coming to mind for me is the idea of being able to have the entire contents of a patch (modules, wires, VST, settings etc stored as a preset, or more should I say as a load patch option that parses the patch and in order to minimize the impact on cpu etc during loading only changes / loads /sets values for anything that has changed. For example, say I had a patch containing a number of audio input and outputs, several sub patches that remain unchanged except for several interface item/control values, one VST that had only the parameters changed and the input output wiring changed, and a new vst to the patch .
In this case, the "patch preset" would load only the several interface item/control values, the vst paramers and input output wiringfor the one vst changed without reloading the entire vst into memory, and of course load the new vst /wiring. All of this with presumably a much more managable hit on cpu/etc while loading the patch changes.

I bring this up as a result of extensive use of the patch load module in my workspace and thinking about how it could be much more resource friendly with less risk to causing glitches in realtime audio / midi when loading (offline) patches in a live scenario. Probably just a dream but I think it could be a good thing to be able to load "patch difference" in this fashion.

[senso]

a patch has so much options, settings that it probably a dream.
Also, suppose I have preset 1,2,3
The preset 2 saves the difference between 1 and 2,
The preset 3 saves the difference between 2 and 3,
so if I go from the P1 to P3 what will happen?

dsenso+++

[gurulogic]

Hmm, yea, maybe not the best specific approach. I guess what I am trying to get at is more along the lines of sub patches being able to have stored macro states or "presets" that would allow a single sub patch in a workspace to be freely changed out for any saved state of that sub patch, including wires, modules, interface items, preset manager etc. In this fashion there could for example be say a list box that you can select the version of the sub patch that you would want loaded. Presumably one would keep the i/o modules the same between sub patch versions, but perhaps this type of sub patch could be in some sort of shell patch that would allow manipulation of the i/o routing between parent patch and sub patch while keeping the parent patch wiring intact.

I do realize that this is already possible to some extent with IML, to load a different saved version of a sub patch and wire it within the parent patch but I find this approach extremely cumbersome to manage as each version of each sub patch requires a manually saved version, and wiring a complex sub patch via IML is painful and because of the way the terminal numbers change when adding modules, adding so much as a data input to the sub patch requires a total rewrite of the referenced terminal pins in IML, and if for example, the way sub patch terminals are referenced changes in the future, all of the links could break.

I am just throwing around ideas and not really expecting anything, but just as food for thought, I think that having some sort of "macro preset" function for this sort of thing would add a very versatile new layer of depth for what is possible in HH.