[L2Ork-dev] Patch private abstractions

Matt Barber brbrofsvl at gmail.com
Wed Aug 5 13:08:27 EDT 2020

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]

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).


On Wed, Aug 5, 2020 at 7:08 AM Guillem Bartrina <guillembartrina at gmail.com>

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

More information about the L2Ork-dev mailing list