[L2Ork-dev] preset demo

[Ivica Ico Bukvic]

On 12/08/2012 11:56 PM, Jonathan Wilkes wrote:
> No, that would require the user to do bookkeeping, which is what most (all?) the
> other Pd preset externals require for setting abstraction instance state.
>
> I'm saying the user would create an abstraction,
> and when the abstraction wants to store abstraction-instance state it writes the
> state as args to the abstraction instead of args to its preset_hub.
>
> For the sake of argument, let's assume that [preset_hub 1] will trigger this
> abstraction arg saving behavior I'm about to describe.  The abstraction author
> puts [preset_hub 1] inside the abstraction he/she is developing, along with some
> gop iemguis connected to preset_nodes, and creates a way of triggering a
> [store 1( message to [preset_hub 1].
>
> Here's what would happen:
>
> 1) User types [abstraction-name] on a canvas
> 2) [abstraction-name] gets created.
> 3) Something triggers the [store 1( message inside the abstraction.
> 4) The state gets _appended_ as args to that abstraction instance.
>
> So if it was [abstraction-name], it becomes [abstraction-name %hidden% whatever]
>
> If it was [abstraction-name arg1 arg2] it becomes [abstraction-name arg1 arg2 %hidden% whatever].
>
> This way abstractions instances can be programmed to save their state without
> requiring the user to "prepare" the canvas in advance with a preset_hub.  This makes
> it possible to create iemstyle properties dialogs-- you pop up a subpatch from the abstraction
> with a nice user-friendly interface, and the user can set colors/values for that abstraction
> instance which gets appended onto the args.
>
> -Jonathan
But what does this give you over what is already there? Sure, creating a 
hub on the root canvas where all abstractions are located is an extra 
step, but either way you will have to save that patch even if you were 
to create an abstraction with your approach as appended values would 
have to be somehow stored after they've been altered. In other words, in 
either case instances of abstractions will have to exist somewhere (on a 
canvas other than their own) to be useful.

Also, I am not sure what you mean by store 1, as that in the current 
iteration would pull whatever default values of the abstraction are. In 
other words, that particular preset would do absolutely nothing. Right 
now, as is the case with K12 mode, all components that are editable by 
users are exposed via gop. Users alter them as they deem fit and then 
once all abstractions have been altered, they store them all (not just 
one of them) into a *single* hub. And herein IMO lies advantage over 
what you're proposing, where you would assign each abstraction settings 
but would not be able to instantaneously change all of the abstractions 
from a single centralized place (as is the case with K12 mode). This way 
the entire root canvas populated with abstractions can be treated 
entirely separately from the rest.

OTOH if you want fully modifiable abstractions in and of themselves, you 
can do that as well. Simply put inside them a hub of whatever name you 
like (it can be a duplicate name or multiple instances of the same 
abstraction, and that doesn't matter due to the way how nodes get 
coupled), and inside the gop-ed area provide means for storing and 
recalling presets (e.g. via a number or a radio). Of course, this does 
not have an ability to save it with the abstraction in case you don't 
have write permissions, and this is where the aforesaid example comes 
into play...