[L2Ork-dev] Patch private abstractions

Guillem Bartrina guillembartrina at gmail.com
Wed Aug 5 07:05:26 EDT 2020


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 

Local scope for these kind of abstractions will be achieved using [ab 

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


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

More information about the L2Ork-dev mailing list