[L2Ork-dev] Patch private abstractions

[Jonathan Wilkes]

On Wed, Jul 29, 2020 at 12:13 PM Guillem Bartrina
<guillembartrina at gmail.com> wrote:
>
> Hi everyone,
>
> in the last meeting I did a small presentation about the feature I'm
> going to implement next.
>
> A quick reminder:
>
> --------------
>
> ### Allow the user to store additional patch definitions within a pd
> file, which can be instantiated as abstractions ###
>
> - creating new abstractions won't require accessing the filesystem
>
> - patch portability is improved, due to the fact that the patch and all
> its abstraction dependencies can be packed into a single pd file
>
> - it fosters the use of abstractions when they should be used.
> Currently, sub-patches are often used only because they are easier to
> create than abstractions, and this leads to code repetition.
>
> Key aspects:
>
>  > the .pd file structure: one main patch and multiple additional patches
>
>  > scope for additional sub-patches: only instantiable by the main patch
> and its sub-patches. They might be instantiable by the additional
> sub-patches themselves too, to be determined.
>
> --------------
>
> Matt suggested implementing this feature in a similar way to how [array]
> or [text] works:
>
>  > There is a template object that contains the abstraction definition.
> This object is not usable: it doesn't accept incoming messages, it
> doesn't have xlets, ... . It basically behaves like a comment, but it
> can be opened to edit the abstraction. For instance, it could be [ab
> define <name>].

I wonder if it even needs to have the ability to be opened. If you get rid of
that requirement then you get rid of a lot of the special cases like not drawing
xlets and such.

In other words the object could just mean, "this is an abstraction
name (or list of names)
to be saved with this patch file." Then the user creates a new object
by that name,
initially getting an empty patch window but filling it up with their
desired content. Saving
works as it does with normal abstractions, just redirecting the "save"
binbuf to an
"#A ab abname etc.;" that follows your hoisted ab definition in the
parent patch.

>
>  > If the corresponding [ab define <name>] abstraction definition exists
> within the scope (the definition is somewhere in the subpatch subtree),
> it can be instantiated by typing, for instance, [ab <name>] in an object.

Ah, I was thinking just [<name>]. But your way does an end run around the
loader and therefore avoids a lot of complexity.

>
>  > If the abstraction definition is edited, all instances of that
> abstraction are updated, as is currently the case with ordinary
> abstractions.

What happens if instance [ab <name>] is edited and saved?

>
>
> I think this one above is an easy and clean way to do this for both
> users and developers.
>
> ---
>
> I've already spent some time trying to figure out how some of the
> related parts of the codebase work, in order to get some inspiration.
> I've checked: [array], [text], [clone], [declare], templates, scalars, ...
>
> I would like to know your point of view in order to build a clear and
> well-defined objective, which will allow me to progress in the most
> direct way.

Two things:

1. As above, I think allowing a click to open a subpatch for [ab define]
is superfluous. Users will tend to immediately do [ab <name>] and
create/edit/save
in the instance as they do with abstractions.

2. Now I'm wondering-- let's say you have [ab define foo] and it opens
a subpatch.
What if that subpatch were just a place to put data to be shared by
all the abstractions?

For example, there could be an [ab send] and [ab receive] so that
abstractions could
register themselves with that shared subpatch which keeps track of their number.

Anyhow, it sounds like you're on the right track.

-Jonathan

>
>
>
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev