<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.</blockquote><div><br></div><div>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.</div><div><br></div><div>Matt</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020 at 3:58 PM Matt Barber <<a href="mailto:brbrofsvl@gmail.com">brbrofsvl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">This is gonna be amazing. Thanks for all your work, Guillem.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'll look forward to seeing the next iteration!</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020 at 2:58 PM Guillem Bartrina <<a href="mailto:guillembartrina@gmail.com" target="_blank">guillembartrina@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,</p>
<p>I've spent some time implementing the first Matt's approach.</p>
<pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">> 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.</pre>
<p> I have found some major problems that I have been able to solve,
some in a cleaner way than others. <br>
</p>
<p>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.</p>
<p>> You could send messages to ab-<name> and access every
instance. <br>
</p>
<p>Done</p>
<p>> 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?</p>
<p>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. <br>
</p>
<pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">> 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,
</pre>
<br>
</div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>
</blockquote></div>