[L2Ork-dev] Patch private abstractions

[Matt Barber]

There are objects which use command line style flags for subcommands
without too much difficulty, if it turns out they're needed.

On Wed, Aug 5, 2020, 1:59 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:

> I'd like to invoke the realtime performance analogy for development
> software that's somewhere on the Purr Data GSoC page. That is: remove
> everything that isn't strictly needed in the hot path of development,
> and then see if the result is enough to fit the common use cases.
>
> Global default scope would at first glance appear to fit that process
> because that's what Pd normally does.But it forces
> $0 for the common case of local scope and also creates unsolvable
> syncing/caching problems for even modestly
> complex data:
>
> 1. On Monday, a user creates [struct foo] in one patch and creates a
> data structure in a 2nd patch.
> 2. On Tuesday, a user only opens the first patch and changes the
> definition of [struct foo], then saves and closes it.
> 3. On Wednesday, a user only opens the 2nd patch.
> 3. On Thursday, a user opens the first patch, then opens the second patch.
>
> The problem is similar for global scope among glists. Unless I'm
> missing an obvious solution, I think solving that problem for
> all cases will eat your development time. Worse, we have no common use
> case where that level of complexity is needed.
>
> Perhaps a good starting point is this: what's the most efficacious way
> to get from this feature to using [clone] to create
> many versions of the abstraction? Say, for the purpose of creating
> massive polyphony. That will be a common use case.
>
> From there I think the best place to go is to just implement it (like
> what you had in your presentation yesterday) and
> make a merge request so we can begin playing around with it and
> testing out some of the common use cases.
>
> One thought-- [ab <name>] makes it tricky to later add subcommands to
> [ab]. A user may have already used
> that name for their abstraction. But again, we know [ab <name>] is
> ergonomic for users and you implemented it already.
> So let's see how far that takes us...
>
> -Jonathan
>
> On Wed, Aug 5, 2020 at 1:09 PM Matt Barber <brbrofsvl at gmail.com> wrote:
> >
> > I see three basic approaches to scope:
> >
> > 1. [ab <name>] abstractions are treated as every bit as local as [pd
> <name>] subpatches, except for each instance has a private $0. [ab <name>]
> definitions do not cross file boundaries, either up to parent or down to
> file abstractions, but the can cross [ab <name>] boundaries, so that [ab
> lob] first defined as root->[pd foo]->[ab bar]->[ab lob] can be
> instantiated anywhere else in root except in another [ab lob] or
> descendant, or across a file boundary. This is probably the most Pd-like,
> and what I'd likely go with by default, as it fits best with the pd/ab
> object analogy.
> >
> > 2. [ab <name>] abstractions are treated as strictly private as file
> abstractions, so definitions inside cannot pass out to parent or down to
> other [ab <name>] descendents]. In other words you treat [ab <name>] as
> though it were a file boundary. This is also pretty Pd-like, and I would
> likely go with it if we were going with a model where you could [ab define
> jinx] and then use [jinx] on its own without needing to call the [ab]
> object.
> >
> > 3. [ab <name>] abstractions are treated as a kind of hybrid. [ab lob]
> defined as [ab bar]->[ab lob] can be used in any instance of [ab bar] and
> descendents (including [ab <name>] descendents) but not in parent or root.
> If root already has an [ab lob] defined, it will be replaced by the new
> definition in [ab bar] instances. This is normal programming local scope,
> is elegant, and is therefore least Pd-like.
> >
> > Other considerations:
> >
> > You could send messages to ab-<name> and access every instance.
> >
> > Name clash. Should the [ab] names be their own separate thing, so that
> [ab counter] and a file abstraction called by [counter] are different? Is
> that even possible? Likewise should [ab float] be possible without
> conflicting with builtin, or [ab z~] without conflicting with an external?
> This could preclude use with [clone], except it could still be done with
> [clone ab-counter] to distinguish from the file-defined [clone counter].
> >
> > I don't have strong opinions about that yet.
> >
> > What happens if one deletes all instances of [ab foo]? I think the patch
> should somehow remember the definition so that it can be instantiated
> again. That probably means it should be hoisted to root and not associated
> with any instances at all.
> >
> > Will [savestate] work? It doesn't work with [clone]. What does
> [initbang] do if you are trying to use it to dynamically patch inside
> instances (I think it should behave about like it does in file
> abstractions, but there could be problems I haven't thought of yet).
> >
> > Matt
> >
> > On Wed, Aug 5, 2020 at 7:08 AM Guillem Bartrina <
> guillembartrina at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> In the last meeting we (more or less) conclude that the most ergonomic
> approach is the one that simply uses [ab <name>], with implicit creation
> and deletion for the shared abstraction definition and an implicit flat
> scope (instantiable by the whole subpatch/abstractions tree, even if first
> definition was in an other branch or a deeper level or inside an
> abstraction).
> >>
> >> Local scope for these kind of abstractions will be achieved using [ab
> $0-<name>].
> >>
> >> * This 'local scope' won't be, in fact, a real local scope but the
> string '$0-name' is much harder to reproduce by the user because he must
> know the '$0' ID of the patch where the local abstraction has been created.
> >>
> >> If a real local scope is wanted then we will have to deal with
> conditional behaviour that may make the feature even harder to implement.
> >>
> >>
> >> The flat scope mentioned above scares me a little because it might be
> the source of a lot of problems. To start with, a clean and strong storing
> and lookup system for the shared abstraction definitions must be designed
> and tested.
> >>
> >> Possible problems:
> >>
> >> - We have to prevent instantiating abstractions within themselves (or
> one of their descendants).
> >>
> >> - Possible name clash with other private abstractions when
> instantiating file-based abstractions.
> >>
> >> - Where should the abstraction definitions be stored within the pd
> file, to prevent code repetition like the subpatches? Maybe hoisted inside
> the root patch definition, as is currently implemented.
> >>
> >> ----------------------------
> >>
> >> The first approach I showed you yesterday was based on Jonathan's
> approach:
> >>
> >> > 1. Implicit as you describe above. Rule: the names go from the root>
> >> > down to the subpatches without
> >> > affecting file-based abstractions in the root or the subpatches. If
> >> > the [ab name] exists inside a file-based abstraction, it doesn't
> >> > affect the parent on which the abstraction was created.
> >>
> >> If I understood correctly, the goal now is the same but the scope now
> crosses file boundaries.
> >>
> >> Best,
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> L2Ork-dev mailing list
> >> L2Ork-dev at disis.music.vt.edu
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200805/219a04ec/attachment-0001.html>