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

[András Murányi]

On Wed, Aug 21, 2013 at 6:11 PM, Ivica Ico Bukvic <ico.bukvic at gmail.com>wrote:

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

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


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

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.

Thanks,

András
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130823/990590df/attachment.html>