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