<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 24, 2013 at 12:26 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">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
<div>On 08/23/2013 02:35 PM, András Murányi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>It's about a bit more than hiding the hub, my goal is a
sort of a modular system of abstractions where i only have
GOP abstractions on the toplevel and I eventually drag
them around or make some live patching between them. So a
lonely [preset_hub] hanging out of each preset managing
abstraction will be a bit like having a single part (say
the carburettor) fixed to the outside of cars :)</div>
</div>
</div>
</div>
</blockquote>
<br></div>
But you only need *one* hub for all abstractions, not one per each
preset abstraction. Have you tried k12 module (type pd-l2ork -k12 to
start it)? See how it works and you'll see it does exactly what you
are looking for.</div></blockquote><div><br></div><div>Oh! I took a look at the k12 module, saved a patch then examined it with "adult" l2ork and instantly I understood what you meant by "Please note that you can have a node inside an abstraction talking to the hub so that you can hide all the sends/receives that may be linked to a hub" before.<br>
</div><div>Thanks a lot. This is just what I needed! (choir singing "<span class="">Ode an die Freude" by Schillet/Beethoven)</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> More seriously, it makes dragging the abstraction
harder, because click-select is not an option then.<br>
</div>
<div>Is there an obstacle/risk in the way of allowing hubs
to be placed inside [pd] subpatches and considering them
being on the parent canvas?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
Subpatches or abstractions? There is nothing preventing you from
having presets per each abstraction by embedding a hub inside it.
The global hub allows all to work in tandem and be
editable/presetable globally which is a lot more powerful and
flexible.<br>
<br>
Also, if you end-up having a sub-patch, how is that any different
than having a hub? In both cases you have an odd object that is not
a part of any abstraction.<br>
<br>
There may be perhaps a reason to have an embedded hub but it won't
be perfect. If you by mistake create two abstractions, both that
reference root canvas with same name, hub prevents this from
happening as it would be impossible to know which hub is responsible
for presets. As a result, one of them would fail to create its hub
(and report error in console but that can be easily missed if one
does not pay attention) and then if you delete the first instance
you will be stuck thinking you are happily storing presets but you
actually aren't.<br>
<br>
HTH<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue;padding:0in 0in 0in 4pt">
<div>
<div>
<div>
<div>
<p class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"></span></p>
<p class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<p class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">As
for the slowness of the array
store/recall, I would need to
investigate to see where the slowness
occurs. Are you sure you are
outputting array values only once? Are
you using array_changed receive? If
so, check how many bangs you’re
getting. There may be a bug in there.
If you can send a distilled version of
the patch I can look into it further.</span></p>
<p class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
I wanted to make you a distilled version by putting only 8
of my sequencer tracks with a hub on a toplevel - I
actually did but it happens to be lightning fast. So it
seems this is again a case where the slowness only occurs
when the whole patch is big. I wonder if there's a remedy.
Also tell me if I shall prepare you a big but clean
example patch.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
Are you using any other non-accelerated objects (as was the case
before)?</div></blockquote><div><br></div><div>Err, perhaps yes. Can we investigate further which objects cause the slowdown? Shall I eventually send you the whole patch, or...?<br><br><br></div><div>András<br></div>
<div> </div></div></div></div>