[L2Ork-dev] Patch private abstractions

Matt Barber brbrofsvl at gmail.com
Tue Aug 4 00:11:29 EDT 2020

Hi, sorry for the late reply; I don't get much email time on weekends.

One thing I feel very strongly about is keeping syntax and semantics
relatively consistent across the various objects. So [ab define] should
work as close as possible to [array define] and [text define]; otherwise
something besides "define" should be used in order not to cause confusion.

I actually agree that [ab define] may turn out to be redundant and that [ab
<name>] could work on its own, using [ab <name>] for every instance. I like
it better than any other options. It would have the advantage of being
similar to [pd <name>], and it would also obviate any issue with loading
objects. The tricky thing may be the patch loading process. It may be worth
sorting instances so that the contents are stored advantageously within the
patch. Its use with [clone] may take a hit as well. If this is the option
we go with, I think saving in the [ab <name>] canvas could save the whole
patch as it does with [pd <name>], but it should also work similarly to
regular abstractions, so some windows may need to be closed etc.

Just thought of something to flag: let's talk about what should happen with

Scope is something I need to think about more. The most pd-like thing would
be flat scope and [ab] objects sharing names between main patch and file
abstractions throwing a "multiply defined" error as with [catch~], say.
Then local scope would be [ab $0-name] as it always is with everything
else. I kind of hate this but it's in keeping with pd design. If we go with
[ab define <name>] and [<name>] instances, scope is a lot more complicated
but should probably follow similar scope to file abstractions, which I
always forget but imagine is strictly local relative to path (that is,
abstraction names can't propagate down to abstraction instances unless they
share a path, in which case it's not really propagation but just flat scope

Thanks for thinking through this so carefully.


On Fri, Jul 31, 2020 at 2:55 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>

> On Fri, Jul 31, 2020 at 7:03 AM Guillem Bartrina
> <guillembartrina at gmail.com> wrote:
> >
> > > 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.
> >
> > As far as I know, the only requirement for objects to be able to be open
> is just having the "menu-open" method defined. Adding a custom open method
> shouldn't be a big problem.
> >
> > > 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.
> >
> > It's a good idea. Users will be able to define all the abstraction names
> at once, instead of
> > creating an [ab define <name>] object for each abstraction. In this way,
> not having the ability to be open makes sense.
> >
> > > What happens if instance [ab <name>] is edited and saved?
> >
> > Yes, I forgot to mention what is supposed to happen. All instances of
> that kind are updated as well.
> >
> > > 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.
> >
> > Yes, I agree.
> > Regarding this approach of defining the abstraction names using [ab
> define <name1> ... <namen>] and editing them through their instances, I
> wonder if it's even necessary to declare the list of abstraction names
> separately.
> > Couldn't it work with just the [ab <name>] instances?
> > - If[ab abs1] is typed into an object and the abstraction definition for
> 'abs1' doesn't exist, then it is created. Otherwise, if the definitions
> already exists, [ab abs1] is going to be an abstraction of that kind.
> The one reason I can think to have explicit name definitions is for
> scoping.
> Compare:
> function foo() {
>     y = 14;
>     z = function() {
>         y = 12;
>     };
> }
> function foo() {
>     var y = 14;
>     var z = function() {
>         y = 12;
>     };
> }
> In the first example, there must be an implicit scoping rule and the
> user is stuck with whatever it is.
> In the second example, the existence or absence of "var" gives the
> user control on the scope of the 2nd "y".
> For [ab] I can think of three approaches:
> 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.
> 2. [ab define] for defining scope. In this design, [ab] names can
> cross file-abstraction boundaries. So the presence of [ab define] says
> "this is the furthest level up that an [ab] by this name will share
> the same contents as the others." Similar to
> how "var" works in javascript, and how [preset_hub] works in Purr Data.
> 3. [ab define] with a numeric argument for climbing out of a
> file-based abstraction to the parent. I do this with [canvasinfo]
> so that the user can build useful abstractions with it. E.g.,
> [canvasinfo 1] affects the canvas that is the parent of its current
> canvas. That way users can build abstractions with it-- otherwise the
> abstraction could only query its own state. So
> [ab define 1] would mean that the names affect everything from the
> canvas that contains our current canvas, down.
> Those are in increasing order of complexity. It's probably best to
> start with your design and see whether that fits most use
> cases.
> > - The abstraction definitions must be hoisted as well so they can be
> found by all objects within the scope, when we are loading the file.
> > - When the last [ab abs1] object is deleted, the abstraction definition
> for abs1 is deleted as well.
> > - The abstractions can be edited/opened from all of their instances.
> >
> > > 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.
> >
> > This has a lot of potential.
> > It's clearly incompatible with the approach which abstraction names can
> be defined with [ab define <name1> ... <namen>]. On the other hand, is
> compatible with the first approach I did, in which abstractions are defined
> individually using [ab define <name>]. It is also compatible with the the
> second approach (this little one above), in which we don't really need to
> define the abstraction name. In this case an optional object [ab data
> <name>] could be created and filled with data that would be shared by all
> the <name> abstractions.
> While it's not a priority, it's something to keep in mind. Matt may be
> able to shed some light on whether something like
> that could be generally useful or just esoteric.
> Best,
> Jonathan
> >
> >
> >
> > Guillem,
> >
> > _______________________________________________
> > 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/20200804/b2a92b2d/attachment.html>

More information about the L2Ork-dev mailing list