[L2Ork-dev] Patch private abstractions

[Matt Barber]

This is gonna be amazing. Thanks for all your work, Guillem.

I'll look forward to seeing the next iteration!

Matt

On Fri, Aug 7, 2020 at 2:58 PM Guillem Bartrina <guillembartrina at gmail.com>
wrote:

> Hi,
>
> I've spent some time implementing the first Matt's approach.
>
> > 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.
>
> I have found some major problems that I have been able to solve, some in a
> cleaner way than others.
>
> For example, I've been forced to add the construction of a dependency
> graph for all ab definitions in order to completely and correctly detect
> the instantiation of ab objects within themselves. I've also used the
> topological sorting of this graph together with some hacky tricks to store
> the ab definitions (hoisted) so that we get the same state [non created
> (red border) ab instances due to dependence issues] when the patch is
> loaded again from the file.
>
> > You could send messages to ab-<name> and access every instance.
>
> Done
>
> > 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?
>
> Ab names are actually their own separate thing. We are not using
> pd_objetmaker anywhere so they cannot lead us to a name clash problem.
>
> > 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.
>
> Right now it remembers the definition until the file is closed. In other words, only the definitions with at least one instance are saved into the pd file.
>
> > Will [savestate] work?
>
> I haven't had time to study this topic.
>
> ---------
> In conclusion:
>
> I started implementing this feature in the cleanest and simplest way that I could. Some problems in the middle of the development have forced me to use some hacky and non-clean techniques to make all the gears of the feature work. Some of them could be fixed, others will force us to rethink the whole feature.
>
> At least now, as Jonathan said, we have a base to start playing around.
>
> I will submit a merge request tomorrow so I need a new branch :)
>
> 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/20200807/72881f63/attachment.html>