<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 6:11 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 class="gmail_quote"><div class="im">---------- Forwarded message ----------<br>From: "Ivica Ico Bukvic" <<a href="mailto:ico.bukvic@gmail.com" target="_blank">ico.bukvic@gmail.com</a>><br>

Date: Aug 21, 2013 11:07 AM<br>Subject: RE: [L2Ork-dev] preset_hub isues/questions<br>
To:  <<a href="mailto:l2ork-dev@bukvic.music.vt.edu" target="_blank">l2ork-dev@bukvic.music.vt.edu</a>><br>Cc: <br><br type="attribution"></div><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal">

<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div><div><div class="im"><div><div><div><div><div><p class="MsoNormal">On 08/16/2013 09:17 AM, András Murányi wrote:<u></u><u></u></p>

</div></div></div>
</div></div></div><div class="im"><div><p class="MsoNormal">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.<u></u><u></u></p>


</div><div><p class="MsoNormal">Interested in your thoughts.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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. :(<u></u><u></u></p>


</div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">András<span style="color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"> <span style="color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal">


<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">It seems to me you are looking for a way to hide preset_hub, correct? If so, you could simply create a canvas in front of the said objects and problem solved. 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. Therefore you only need a hub on the toplevel patcher and nothing else.</span></p>

</div></div></div></div></div></div></div></div></blockquote><div><br></div><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 :) 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> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div link="blue" vlink="purple" lang="EN-US"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </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>

<br></div><div>Thanks,<br></div><div> </div><div></div></div>András
</div></div>