[L2Ork-dev] Patch private abstractions

Matt Barber brbrofsvl at gmail.com
Fri Aug 7 22:28:13 EDT 2020

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

I'm of two minds on this. I can think of very good reasons to keep all
definitions in the file, but it would also mean holding onto unwanted
definitions as well. I think that's where some kind of hub object that
keeps track of all of them could be good. Not sure what to call it; [ab
control] maybe (meaning "control" would be a reserved symbol). The idea
would be to make this feature as nondestructive as possible in case of
error, crash, etc. So you could keep everything in the file whether or not
any are instantiated, and [ab control] could have access to them. Then you
could send commands like [get( to get a list of everything available, and
[delete( to get rid of an unwanted definition. This last thing is kind of
weird in that you usually don't have to interact with the patch in order to
build it. There could be [clear( or something to delete everything that
doesn't have an instance. Not sure.


On Fri, Aug 7, 2020 at 3:58 PM Matt Barber <brbrofsvl at gmail.com> wrote:

> 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/06d6a387/attachment-0001.html>

More information about the L2Ork-dev mailing list