[L2Ork-dev] Bad source tarball

[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: Monday, July 16, 2012 1:39 PM
> Subject: RE: [L2Ork-dev] Bad source tarball
> 
>>  Ok, I see now...
>> 
>>  I feel like you've left out the #1 most convenient use case here, and 
> like
>>  every other extant preset system in Pd it remains nearly as cumbersome for
>>  this specific use case as someone just rolling their own preset system
> with
>>  abstractions.  Here's the use case I'm talking about:
>> 
>>  I get an idea for a patch.  I start building it.  After experimenting with
> the
>>  state for about 30 minutes I get a sound I like and want to save all the
> values
>>  I've set to get it.  But oops, this was just supposed to be a quick
> experiment
>>  and I didn't set it up for state saving.  At this point it is nearly as
> easy to put in
>>  a bunch of [loadbang]--[set some_value( as it is to retrofit the patch
> with
>>  your preset system.
>> 
>>  I'm making this specific critique because your object current fails to
> create if I
>>  don't give it any argument.  So why not make preset_hub apply to all
> canvas
>>  local objects that you support when no arg is given?  That way someone who
>>  just wants to quickly remember the state can create two objects and be
>>  done with it in 10 seconds.
>> 
>>  Or if that seems hacky, maybe having another creator name for triggering
>>  canvas-wide state, like [canvas-preset]. Then no args = all supported
> objects,
>>  iemgui = iemguis, and so on as you add categories of objects.
>> 
>>  Anway, neat class!  I'll have to play with it some more...
> 
> Loadbang + number/symbol plus 2 connections is still more than twice the
> work than just a preset with a single connection. Also, the name is critical
> since you can have multiple hubs. What about having multiple abstractions
> where all their members (if they are built properly) connect to the one
> master hub? Create one hub on the root canvas and you can store preset with
> a single click for all abstractions. Isn't this fairly close to what 
> you're
> looking for?

It doesn't solve the specific case where I just start with iemguis then get something
where I suddenly want to save the state.

Would it be unwieldy to just have preset_hub with no args apply to all canvas local
iemguis?  It's just a really nice shortcut, especially in teaching situations where you
quickly want to save state and come back to it.

> I would even go as far as to argue that some ways it is even
> more powerful than pattrstorage on Max as each node can also request
> storing/recall from the hub, regardless where it is located (e.g. in a
> sub-patch, abstraction, whatever).

I was just thinking about interpolation after I emailed you.  For example,
[recall 4.3(--[preset_hub]

I'm trying to think of a way you could make the interpolation scheme user-definable,
so that somehow they can receive the values to use to interpolate, do some calculations
then send them on their way.  But I can't think of anything straightforward yet.

> 
> One of the core reasons for creating this was abstraction control. None of
> the current preset models are capable of this--even sssad only works as long
> as each abstraction has a unique name (which is impossible if you are using
> two instances of the same abstraction, or at least impossible in a way that
> can be recalled after the patch has been restored later since canvas names
> would have changed and $0 would be of no use). In this case it is not
> necessary and this works perfectly fine.

So [preset_hub foo] applies to the canvas and all its children including abstractions.
Is that right?

> 
> Hubs in this case are already canvas-specific. Fail-safe system that
> prevents creation of same-named or nameless hubs on the same canvas (they
> can exist on multiple canvases) is critical to making sure they don't
> pollute each other's data. If you create one hub on the root canvas, you can
> simply connect any object you wish to monitor with a preset_node and you're
> done.
> 
> If one were to put all this functionality inside objects that are
> preset-able they would grow into unwieldy gargantuan monolithic designs and
> the whole presetting model would be seriously limited in terms of its
> expanadability.
> 
> Also, note how the node refuses to connect to objects it is not aware of how
> to deal with (data type support).

That seems like it doesn't jibe with the paragraph above it.  Do you have to somehow
register new objects to be accepted by your system?

-Jonathan

> 
> Cheers!
>