[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: Saturday, December 8, 2012 2:35 PM
> Subject: RE: preset demo
> 
>>  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.
> 
> But why would you want to have user expect inferred features of a canvas.

Yes, this is probably a confusing way to get the functionality I'm asking about.

[...]

> Another thought, if one had a preset_hub embedded in each canvas, then the
> abstraction would have one as well which means that you could never do the
> granular approach I explained in earlier email where one hub controls all
> abstractions. This is because all nodes would detect the hub inside the
> abstraction before they would detect the one on the parent and as such could
> never be controlled outside the abstraction itself *unless* you specify
> different node name than the default canvas one, in which case you are back
> to square one except that the whole thing is a lot more confusing.
> 
> Last thought, one could go as far as embedding the external into the canvas
> and then in the canvas properties assigning canvas preset hub name. But
> this, to me at least, seems a lot more confusing and less straightforward
> than simply using the preset_node and preset_hub...

Here's an idea-- what if you could redirect the hidden args to be appended as
abstraction args?  That way they could get saved with the parent patch, but in
a way that is both transparent to the user and consistent with the current behavior.

This would mean that users could code their own iemgui-style abstractionswhere
settings like colors/settings/state/etc. could get saved  with each instance.

-Jonathan