[L2Ork-dev] preset demo

[Jonathan Wilkes]

----- Original Message -----
> From: Ivica Ico Bukvic <ico at vt.edu>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "'An open mailing list for a world-wide network of aspiring L2Orkists, L2Ork developers, contributors, and supporters.'" <l2ork-dev at disis.music.vt.edu>
> Sent: Saturday, December 8, 2012 9:22 PM
> Subject: Re: preset demo
> 
> On 12/08/2012 09:04 PM, Jonathan Wilkes wrote:
>>  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 
> 
> So, what you're saying is [abstraction node_name]

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

> and inside it 
> [preset_node $1] where $1 is recast into node_name? If so, this currently 
> doesn't work since preset_node does not know what to make of $1 but if I 
> allow preset node context to be settable (as in [set blah<), then this could 
> be added relatively easily, as in:
> 
> loadbang
> |
> $1
> |
> set $1
> |
> preset_node whatever
> 
> However, for this to work, both preset_node and preset_hub should also allow for 
> argument-less creation which I guess I could implement once we have this release 
> finalized.
> 
> Best wishes,
> 
> -- Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound & Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Head, ICAT IMPACT Studio
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
>