[L2Ork-dev] Fwd: RE: preset_hub isues/questions

[Ivica Ico Bukvic]

---------- Forwarded message ----------
From: "Ivica Ico Bukvic" <ico.bukvic at gmail.com>
Date: Aug 21, 2013 11:07 AM
Subject: RE: [L2Ork-dev] preset_hub isues/questions
To: <l2ork-dev at bukvic.music.vt.edu>
Cc:

** **

On 08/16/2013 09:17 AM, András Murányi wrote:****

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

Interested in your thoughts.****

** **

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. :(
****

** **

András****

****

** **

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

** **

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

** **

Thanks!****
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130821/4d336fed/attachment-0001.html>