[L2Ork-dev] preset demo

[Ivica Ico Bukvic]

On 12/07/2012 05:29 PM, Jonathan Wilkes wrote:
> One sticking point:
> * an abstraction can't programmatically manage its own state with preset_hub.
> For a counterexample,
> think of a gop abstraction with a "Put" menu array with 10 elements that act as a
> "multislider".  The abstraction author can take a "save" message that will save the
> multislider state to a file, and a "load" message that recalls it.  Since the data is
> just floats they can even save from one instance and load to another.  A similar
> gop iemgui abstraction can't use your preset_hub system to do this because the state
> is bound to the abstraction's file.
This is very much possible as well. Simply put a hub inside the 
abstraction (it can have whatever name and it will capture all nodes in 
its scope in the root patch of the abstraction and any sub-patchers 
sub-abstractions it may have. You can have another hub that may bear 
different or even same name above it (as in root patch in which you 
would also create an instance of the aforesaid abstraction) and it would 
scoop up anything else not taken by the hub inside the abstraction--in 
other words, nodes seek first appropriate hub above them and by above I 
mean in the same patcher or parent patcher, it does not matter what 
order they are within the glist in respect to the hub), create presets 
and save them with the patch. Node positions will be always constant 
relatively to the hub's position since they are located within the same 
scope (patch), even when instantiated within another patch, and even if 
you change them by editing the patch, pd-l2ork will make sure 
adjustments are taken into account by readjusting location index 
accordingly (preset_hub checks its referenced node locations whenever a 
destructive edit takes place that may alter their locations, e.g. 
cutting objects that may change glist and consequently ordinal position 
of objects further down the glist, some of which may be the said nodes). 
This way you will never lose referenced nodes and their respective presets.

This way every time you instantiate the said abstraction, you will also 
instantiate all its presets and if you can access presets via some kind 
of a gui (or a receive, or whatever) to change its current preset, it 
will work just fine and not be affected by changes in another 
abstraction even if it is an instance of the exact same abstraction.

You can also have a hub in the patcher hosting all the abstractions that 
may have preset-able components, as is the case with K12 module  (see 
how we use preset abstraction to store data from all other 
abstractions). In this case hub is a hidden object in the root canvas 
(we use a special preset_hub flag designed specifically for the k12 
mode), and because nodes have ability to tell hub when to store and 
recall, preset abstraction simply has a single dummy node that is used 
to broadcast requests to store or recall data to the hidden hub in the 
root canvas. On top of that you can have multiple instances of the same 
abstraction and each abstraction's settings being unique (which is a lot 
more flexible than saving an abstraction with an embedded preset list, 
which of course has its uses as well (such as let's say an F/X 
abstraction that has n most commonly used settings, but is simply not as 
flexible, as now you can alter each abstraction with maximum 
granularity, namely per each preset-able variable, rather than picking 
from a preset collection of prebuilt presets).

Pretty nifty, no?

>
> Also, even though your state-saving syntax is more complex than a simple
> series of floats, it wouldn't matter with the abstraction example because the user won't
> be changing the ordering inside the abstraction, and the ordering won't be changing
> from instance to instance.  (Well, unless dynamic patching is going on, but that's another
> matter.)
>
> -Jonathan