[L2Ork-dev] preset demo

Ivica Ico Bukvic ico at vt.edu
Sat Dec 8 19:35:12 UTC 2012


> 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. I
made it invisible in K12 because it is targeted towards kids who may not
want to know all about how things like presets work. OTOH, pd-l2ork is a
programming environment and while it offers some shortcuts, most (all?) of
them are not as fundamental as embedding an external into a canvas (which is
what you are essentially suggesting). Why is it a problem to put a hub onto
a canvas or match node names to the hub, for that matter? I guess I can
allow for generic node and hub that would be nameless which would make
things easier for people to share things without having to guess node names
within abstractions, but the actual embedding of the preset_hub into the
canvas does not seem like the best option to me, particularly since then you
need to have a node to communicate with the hub but that communication does
not offer all options like direct communication with the hub... Besides, if
someone is using abstractions, the logical conclusion is that they would be
putting it onto some kind of a canvas and if so, that means they would have
more than just those abstractions to make things happen. Adding a hub would
be certainly one of those things.

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




More information about the L2Ork-dev mailing list