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.
Statistics: Posted by gurulogic — 22 Dec 2016, 23:28
]]>
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+++
Statistics: Posted by senso — 21 Dec 2016, 15:25
]]>
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.
Statistics: Posted by gurulogic — 27 Nov 2016, 03:03
]]>
Statistics: Posted by gurulogic — 09 Nov 2016, 22:36
]]>
For now I haven't any clear solution for you but I'll think about a selective "store in preset" option.
Statistics: Posted by senso — 09 Nov 2016, 22:11
]]>
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.
Statistics: Posted by gurulogic — 20 Oct 2016, 02:35
]]>