[L2Ork-dev] Bad source tarball

[Ivica Ico Bukvic]

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

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.

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

Cheers!