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

[Ivica Ico Bukvic]

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.

> 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)?
>
> Thanks,
> András
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130823/9b4b9b90/attachment.html>