<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 5:24 PM, Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico.bukvic@gmail.com" target="_blank">ico.bukvic@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div lang="x-western"><div><div class="h5">
<div>On 08/16/2013 09:17 AM, András
Murányi wrote:<br>
</div>
<blockquote 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 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 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></div></div>
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>
</div>
</blockquote><div> <br></div><div>Thanks for the explanation. I took some time to think this over and to do some testing as well as to go through a food poisoning (mexican in Budapest!) <br><br></div><div>You definitely have the point where you say (in my words) that the preset data have to be stored at the toplevel patch, otherwise different instances of the abstractions will overwrite each others' data. I wished I could disregard any "architectural" concern and present a case from the user's perspective but at the and it boils down to this simple point (where both perspectives actually meet).<br>
<br></div><div>Now my remaining concern of a user is that I wish to have no or very few non-gop opbejcts and cables in my toplevel patch. Therefore I wish I could have my preset_hubs A.) somewhere remote on the canvas, connected by send/recieve, or even by a direct send like [s preset_hub_foo] (currently not possible as you mentioned before), or B.) in a subpatch [pd mypresethub foo] which at the moment doesn't work either. I cannot bring up real technical arguments for the send/recieve method but I would feel it being something "natural" if implemented. As for putting a preset_hub in a [pd] subpatch: it is, from some perspective, still in the toplevel patch; it gets saved with the toplevel patch and there are no overwriting instances, so I see it as something viable.<br>
</div><div>Interested in your thoughts.<br></div><div><br></div><div>BTW, tested preset_hub_array, and in my case (present in 8 sequencer tracks with the same scope, each recalling a 64-long Array and then setting 64 toggles through a simple tabread->pack->message->route chain) it is slow. :(<br>
</div><br><div>András
</div></div></div></div>