<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi Guillem, all.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">You'll have to forgive me – I'm operating on a lag of a few days and am constantly trying to catch up on my emails.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">See below:</div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
What's the policy in accordance to pd vanilla? Are we able to add, <br>
modify or remove anything regarding pd vanilla? Does Purr Data has to be <br>
fully compatible with it?<br>
<br>
I'm not sure if Matt mentioned the need to gain familiarity with [clone] <br>
module to being forced to respect the vanilla's implementation or <br>
because it can be somehow useful in accordance to my project.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">Both. Your project has a couple of parts. The one that would allow abstractions to be defined from within a patch rather than loaded from a different file would have to be compatible with all the structures in Pd that depend on abstractions. That's a big lift, and if it's too much for this summer, we can take some first steps and then continue to work on it later. In any case, [clone] is an interesting thing in Pd because it's relatively new, and anything you do with abstractions here will need to be compatible with it. But also, the way clone works could give you some ideas for how you go about some of these details in a way that makes it more compatible for the future.</div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
---<br>
<br>
Now, related to my project and its goals:<br>
<br>
Do all of you agree with all the parts? Are there something that has to <br>
be modified, refined or discussed?<br>
<br>
The first part is about improving the subpatches creation process. It <br>
will be accelerated by giving the user the option to automatically <br>
create a subpatch from a selection of objects, with the necessary inlets <br>
and outlets.<br>
<br>
Is all clear about this first part? Do you have any thoughts or advice?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">I think we should focus on this one to start because it won't change much in the architecture of Pd. A few things to think about here:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">1. Are there any circumstances in which moving something into a subpatch could change program flow in unpredictable ways? I can't think of any at the moment but I'm sure there's some possibility.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2. When you grab a set of objects to encapsulate, the hardest part, as Jonathan says, will be to figure out inlets, outlets, and connections. One problem to contend with: suppose this simple case:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">[bang(</div><div class="gmail_default" style="font-family:verdana,sans-serif"> |</div><div class="gmail_default" style="font-family:verdana,sans-serif">[t b b]</div><div class="gmail_default" style="font-family:verdana,sans-serif"> |    |  \</div><div class="gmail_default" style="font-family:verdana,sans-serif"> |    |    \</div><div class="gmail_default" style="font-family:verdana,sans-serif">[0(  [1(  [2(</div><div class="gmail_default" style="font-family:verdana,sans-serif"> |     |     |</div><div class="gmail_default" style="font-family:verdana,sans-serif">[pack 0 0 0]</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Imagine the user chooses to encapsulate everything after [t b b]. Does the subpatch now have three inlets and preserve the fanout from the right side of [t b b], or does it have two inlets and a fanout after the rightmost inlet in the subpatch?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3. Figuring out undo might be worth doing fairly early. </div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The second part is a little more tricky. The final goal is to improve <br>
abstraction creation process as well. I proposed two possible solutions <br>
(not incompatible one each other), based on what I understood from the <br>
original idea post.<br>
<br>
The first one is exactly the same as I proposed for subpatches but for <br>
abstractions instead. The automatically created abstraction will be <br>
saved by popping up a File Chooser.<br>
<br>
Do you agree?  Do you have any thoughts or advice?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">I think of this as actually part of the auto-encapsulation for subpatches. The mechanics of it will be the same more or less. The differences will be how the file will be saved and loaded. A tricky part here will be path handling – we can talk about this later.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The second is to be able to store multiple patch definitions into a <br>
single .pd file. I don't know (yet) how this part will affect to the <br>
current system, if a lot of changes/redesign is required or if it is <br>
even feasible.<br>
<br>
I hope and suppose it's feasible without having to modify any critical <br>
part of the current structure. Jonathan mentioned that it could be <br>
implemented leveraging or adapting some of the current <br>
abstractions/subpatches system.<br>
<br>
I want to be sure that you want to add this feature to the system <br>
instead of something more critical or wide-used.</blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">This is my favorite part of your proposal, but it's also by far the hardest. I'm willing to let it take longer than just this summer. But see below:</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In addition, this feature produces a bunch of questions that must be <br>
answered:<br>
<br>
If there are more than one (root) patch definition inside a pd file...<br>
<br>
- Is there or has to be a main one? In that case, which one?<br>
<br>
- When do we erase one of those extra patch definitions? One options <br>
could be when the user deletes the last instantiation of it, but it's <br>
not the only one.<br>
<br>
- Will the additional patch definitions be only "visible" (instantiate) <br>
by the "main" patch of the pd file? Or by the other patches in the file <br>
as well? And what about external patches (not in the pd file)?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Basically I think this should work more or less the way it does with [declare] and path structure. I haven't thought of everything here yet so we'll have to keep thinking about it. I think having a name clash should be an error, but I could see having an intelligent way of scoping where a patchdef in a parent can be replaced by one of the same name in a child... but perhaps this should be discouraged.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- ...<br>
<br>
Currently you can edit abstractions from the patch that instantiates <br>
them by clicking "open" in the contextual menu. I assume the same <br>
technique will apply to be able to edit the additional patch definitions <br>
inside a pd file from the patch that instantiates them (and actually the <br>
only way to do it, as we can't access them directly [right?]).<br>
<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif">Right. I'd envision being able to edit both from the definition and any instance. Anyway I think it will be difficult to try to think about everything at once, so let's start on the subpatch problem first and see how far we get and how quickly.</div></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">MB</div></div></div>