[L2Ork-dev] Patch private abstractions

[Guillem Bartrina]

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,


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