[L2Ork-dev] Patch private abstractions

[Jonathan Wilkes]

On Fri, Aug 7, 2020 at 10:28 PM Matt Barber <brbrofsvl at gmail.com> wrote:
>>
>> 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.

You could have an [ab sanity] which, if present, just holds a canvas
that instantiates a copy of each abstraction at the creation time.
Then everything you define would be kept as long you keep your [ab
sanity] because the number of instances wouldn't go below 1.

In other words, in the constructor for [ab <name>]:

1. Is there an [ab sanity] in existence?
2. If so, instantiate [ab <name>] there
3. repeat for each new [ab <name>], maybe making a nice alphabetical
column for the ab'bers

Could even have an [ab splain] where you can type a short description
that shows up next to the instance in the  [ab sanity] subpatch. :)

-Jonathan



>
> Matt
>
> 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
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev