[L2Ork-dev] preset_hub isues/questions

[András Murányi]

On Fri, Aug 16, 2013 at 5:24 PM, Ivica Ico Bukvic <ico.bukvic at gmail.com>wrote:

>  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>wrote:
>
>> On Aug 15, 2013 5:16 PM, "András Murányi" <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
>

Thanks for the explanation. I took some time to think this over and to do
some testing as well as to go through a food poisoning (mexican in
Budapest!)

You definitely have the point where you say (in my words) that the preset
data have to be stored at the toplevel patch, otherwise different instances
of the abstractions will overwrite each others' data. I wished I could
disregard any "architectural" concern and present a case from the user's
perspective but at the and it boils down to this simple point (where both
perspectives actually meet).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130821/42fac5c7/attachment.html>