<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-html" lang="x-western">
<div class="moz-cite-prefix">On 08/16/2013 09:17 AM, András
Murányi wrote:<br>
</div>
<blockquote
cite="mid:CAJtGUK59=8gcyTBupBji+=LwD0Oi52z5V1NfpBYxzQaGCCLHCg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Aug 16, 2013 at 2:22 AM,
Ivica Ico Bukvic <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ico.bukvic@gmail.com" target="_blank">ico.bukvic@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<p dir="ltr">On Aug 15, 2013 5:16 PM, "András Murányi"
<<a moz-do-not-send="true"
href="mailto:muranyia@gmail.com" target="_blank">muranyia@gmail.com</a>>
wrote:</p>
<p dir="ltr">> Did some testing and we're almost
where I wish to be (if ever possible). What doesn't
work right now is a scenario where I have the hub in
abstraction A and its nodes in abstraction B, and A
and B are embedded on the same canvas (C). Both A and
B get their scope symbol from the abstractions'
arguments. Something like this:<br>
> [mysequencertrack track0 scope0]<br>
> [mysequencertrack track1 scope0]<br>
> [mysequencertrack track2 scope0]<br>
> [mypresetsaver scope0]</p>
<p dir="ltr">That is because hub only sees stuff in its
scope, meaning anything inside its patcher and its
subpatches. I think what you need is what k12 mode
uses which is a hub in the parent patch that hosts
both abstractions a and b since you will have to save
that one anyhow at some point, so it shouldn't be a
problem for it to be responsible for presets as well.
Otherwise you will run into a lot of scope issues.</p>
</blockquote>
</div>
I see. Can I respectfully challenge this idea?<br>
</div>
<div class="gmail_extra">Is there a reason for not allowing a
hub with a given scope symbol/name to connect to any node
with the same scope symbol/name, regardless of their
placement? Now that $ args work with preset_hub, I don't see
why they couldn't connect just like [s foo] and [r foo] in a
location-independent way. Of course I mean if there's a
reason from the user's perspective I'd like to learn it.<br>
<br>
</div>
<div class="gmail_extra">Thanks,<br>
</div>
<div class="gmail_extra"><br>
András </div>
</div>
</blockquote>
You are more than welcome to challenge the idea. As a matter of
fact I would very much like to encourage that kind of discourse as
this is how progress is usually made. :-)<br>
<br>
At any rate, the reason why I believe this is a bad idea is
because that is how I originally conceived of k12 module--namely
having a bunch of abstractions, one of which was a preset holding
abstraction that I will refer to here as the "preset abstraction."
The problem with this design is that every time you store a new
preset the "preset abstraction" would be marked as "dirty" since
its contents have been changed. This would therefore force you to
save the "preset abstraction" which is a system abstraction (as in
shipped with your ecosystem of abstractions), not necessarily
designed to be changed every time. It would also obliterate any
presets you may have stored with a different patch that may have
used the same "preset abstraction" and other abstractions with it
(I hope you'll agree with me that using an abstraction is because
you would want to use it in more than one place). As a result you
would never be able to use the same "preset abstraction" in
multiple contexts as the presets would obliterate each other
depending what you saved last. As a result, the only sensible way
that I could come up within the k12 mode where every abstraction
is preset-able is to have an invisible hub embedded in every
patcher which makes sense since every parent patch is essentially
a new patch/piece/whatever that just happens to use a series of
abstractions. Now, you could still have a preset-store/recall
abstraction that could reference the hub in the parent patcher (as
is the case with the K12 mode) because every node can forward
those requests to its parent hub.<br>
<br>
That said, now that I've implemented saving presets to files the
only way I can think of that you would not have to mark
abstraction as dirty is by having it save its presets into an
external file and this is where you would not have to worry about
the previous dirty abstraction issue. So, perhaps this could be an
isolated case where you could set up a global hub that exists in
its topmost parent context but that could easily cause problems
like having two of those abstractions and not knowing which one is
primary, etc.<br>
<br>
HTH<br>
</div>
</body>
</html>