[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: Sunday, December 9, 2012 12:54 AM
> Subject: Re: preset demo
> 
> 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?

Modularity and the ability to use the preset class as part of a black box
design.  It might be better to have a separate class for this since preset_hub
is already pretty complex, but I think the idea of having hidden args in
an abstraction fills a need in Pd that's otherwise very difficult to manage.

(See below.)


> 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.

It's the difference between creating an iemgui as one currently does, and
creating an iemgui plus some [iemgui_state] helper object in the cases where
you want to save non-default slider color, width, etc.  But we're talking about two
different use cases.

> 
> Also, I am not sure what you mean by store 1,

I mean what [store 1(--[preset_hub] currently does, except saving the
args to the abstraction as I said above.  But when I say "something triggers" the
message, this could be anything-- the user clicking "Ok" on a homemade
properties dialog subpatch, the patch responding to some external event,
a metro in the patch sending a bang after the user has messed with some
sliders, etc.  I'm not talking about a loadbang.

> 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.

We're talking about two different things.  I'm thinking about ways in which
abstractions can be more expressive and less like second class citizens in
Pd-- especially when compared with externals.  You're talking about efficiently
defining what state is for a patching environment and controlling it centrally.

The reason I'm describing this is because Pd doesn't give its users much
power in the realm of abstraction development.  There are several externals
for dealing with abstraction arguments but even utilizing those it remains a
pain not only to parse arguments, but also to set them to something else
when Pd isn't really designed to do that in a user-friendly way.


Anyway I think there's something in your preset design that can allow users
to do an end run around these long-standing problems and be able to
effectively get and set state for abstraction instances without even knowing
or caring about how Pd handles it under the hood.


-Jonathan


> 
> 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...
>