[L2Ork-dev] preset demo

[Jonathan Wilkes]

----- Original Message -----
> From: Ivica Ico Bukvic <ico at vt.edu>
> To: Jonathan Wilkes <jancsika at yahoo.com>; "An open mailing list for a world-wide network of aspiring L2Orkists, L2Ork developers, contributors, and supporters." <l2ork-dev at disis.music.vt.edu>
> Cc: 
> Sent: Friday, December 7, 2012 10:49 PM
> Subject: Re: preset demo
> 
> 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?
> 

I think my question is this: how can you make it so that users can have access to
something comparable to your invisible k12 hub?

In other words, a programmatic way for abstraction instances to be able to tell the
parent canvas to store their state on its behalf, and without the user having to plant a
preset_hub on that canvas.  Basically I'm trying to avoid requiring the user to manually
creating the [preset_hub some_name] and having to match the "some_name" inside the
abstractions.

I'll mock up an example if this isn't clear.

-Jonathan