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

[András Murányi]

On Sat, Aug 24, 2013 at 12:26 AM, Ivica Ico Bukvic <ico.bukvic at gmail.com>wrote:

>  On 08/23/2013 02:35 PM, András Murányi wrote:
>
>
>  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 :)
>
>
> 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.
>

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.
Thanks a lot. This is just what I needed! (choir singing "Ode an die
Freude" by Schillet/Beethoven)



>
>    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?
>
>
> 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.
>
> 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.
>
> 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.
>
> HTH
>
>
>
>
>>
>>
>> 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.
>
>
> Are you using any other non-accelerated objects (as was the case before)?
>

Err, perhaps yes. Can we investigate further which objects cause the
slowdown? Shall I eventually send you the whole patch, or...?


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