[L2Ork-dev] preset_hub isues/questions

[Ivica Ico Bukvic]

On 08/16/2013 09:17 AM, András Murányi wrote:
> On Fri, Aug 16, 2013 at 2:22 AM, Ivica Ico Bukvic 
> <ico.bukvic at gmail.com <mailto:ico.bukvic at gmail.com>> wrote:
>
>     On Aug 15, 2013 5:16 PM, "András Murányi" <muranyia at gmail.com
>     <mailto:muranyia at gmail.com>> wrote:
>
>     > Did some testing and we're almost where I wish to be (if ever
>     possible). What doesn't work right now is a scenario where I have
>     the hub in abstraction A and its nodes in abstraction B, and A and
>     B are embedded on the same canvas (C). Both A and B get their
>     scope symbol from the abstractions' arguments. Something like this:
>     > [mysequencertrack track0 scope0]
>     > [mysequencertrack track1 scope0]
>     > [mysequencertrack track2 scope0]
>     > [mypresetsaver scope0]
>
>     That is because hub only sees stuff in its scope, meaning anything
>     inside its patcher and its subpatches. I think what you need is
>     what k12 mode uses which is a hub in the parent patch that hosts
>     both abstractions a and b since you will have to save that one
>     anyhow at some point, so it shouldn't be a problem for it to be
>     responsible for presets as well. Otherwise you will run into a lot
>     of scope issues.
>
> I see. Can I respectfully challenge this idea?
> Is there a reason for not allowing a hub with a given scope 
> symbol/name to connect to any node with the same scope symbol/name, 
> regardless of their placement? Now that $ args work with preset_hub, I 
> don't see why they couldn't connect just like [s foo] and [r foo] in a 
> location-independent way. Of course I mean if there's a reason from 
> the user's perspective I'd like to learn it.
>
> Thanks,
>
> András
You are more than welcome to challenge the idea. As a matter of fact I 
would very much like to encourage that kind of discourse as this is how 
progress is usually made. :-)

At any rate, the reason why I believe this is a bad idea is because that 
is how I originally conceived of k12 module--namely having a bunch of 
abstractions, one of which was a preset holding abstraction that I will 
refer to here as the "preset abstraction." The problem with this design 
is that every time you store a new preset the "preset abstraction" would 
be marked as "dirty" since its contents have been changed. This would 
therefore force you to save the "preset abstraction" which is a system 
abstraction (as in shipped with your ecosystem of abstractions), not 
necessarily designed to be changed every time. It would also obliterate 
any presets you may have stored with a different patch that may have 
used the same "preset abstraction" and other abstractions with it (I 
hope you'll agree with me that using an abstraction is because you would 
want to use it in more than one place). As a result you would never be 
able to use the same "preset abstraction" in multiple contexts as the 
presets would obliterate each other depending what you saved last. As a 
result, the only sensible way that I could come up within the k12 mode 
where every abstraction is preset-able is to have an invisible hub 
embedded in every patcher which makes sense since every parent patch is 
essentially a new patch/piece/whatever that just happens to use a series 
of abstractions. Now, you could still have a preset-store/recall 
abstraction that could reference the hub in the parent patcher (as is 
the case with the K12 mode) because every node can forward those 
requests to its parent hub.

That said, now that I've implemented saving presets to files the only 
way I can think of that you would not have to mark abstraction as dirty 
is by having it save its presets into an external file and this is where 
you would not have to worry about the previous dirty abstraction issue. 
So, perhaps this could be an isolated case where you could set up a 
global hub that exists in its topmost parent context but that could 
easily cause problems like having two of those abstractions and not 
knowing which one is primary, etc.

HTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130816/987b0665/attachment.html>