[L2Ork-dev] Encapsulation Ergonomics

[Matt Barber]

Hi Guillem, all.

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.

See below:

>
> What's the policy in accordance to pd vanilla? Are we able to add,
> modify or remove anything regarding pd vanilla? Does Purr Data has to be
> fully compatible with it?
>
> I'm not sure if Matt mentioned the need to gain familiarity with [clone]
> module to being forced to respect the vanilla's implementation or
> because it can be somehow useful in accordance to my project.
>
>
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.





> ---
>
> Now, related to my project and its goals:
>
> Do all of you agree with all the parts? Are there something that has to
> be modified, refined or discussed?
>
> The first part is about improving the subpatches creation process. It
> will be accelerated by giving the user the option to automatically
> create a subpatch from a selection of objects, with the necessary inlets
> and outlets.
>
> Is all clear about this first part? Do you have any thoughts or advice?
>

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:

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.

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:

[bang(
 |
[t b b]
 |    |  \
 |    |    \
[0(  [1(  [2(
 |     |     |
[pack 0 0 0]

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?

3. Figuring out undo might be worth doing fairly early.




>
> The second part is a little more tricky. The final goal is to improve
> abstraction creation process as well. I proposed two possible solutions
> (not incompatible one each other), based on what I understood from the
> original idea post.
>
> The first one is exactly the same as I proposed for subpatches but for
> abstractions instead. The automatically created abstraction will be
> saved by popping up a File Chooser.
>
> Do you agree?  Do you have any thoughts or advice?
>

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.



>
> The second is to be able to store multiple patch definitions into a
> single .pd file. I don't know (yet) how this part will affect to the
> current system, if a lot of changes/redesign is required or if it is
> even feasible.
>
> I hope and suppose it's feasible without having to modify any critical
> part of the current structure. Jonathan mentioned that it could be
> implemented leveraging or adapting some of the current
> abstractions/subpatches system.
>
> I want to be sure that you want to add this feature to the system
> instead of something more critical or wide-used.


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:



>


> In addition, this feature produces a bunch of questions that must be
> answered:
>
> If there are more than one (root) patch definition inside a pd file...
>
> - Is there or has to be a main one? In that case, which one?
>
> - When do we erase one of those extra patch definitions? One options
> could be when the user deletes the last instantiation of it, but it's
> not the only one.
>
> - Will the additional patch definitions be only "visible" (instantiate)
> by the "main" patch of the pd file? Or by the other patches in the file
> as well? And what about external patches (not in the pd file)?
>

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.

>
> - ...
>
> Currently you can edit abstractions from the patch that instantiates
> them by clicking "open" in the contextual menu. I assume the same
> technique will apply to be able to edit the additional patch definitions
> inside a pd file from the patch that instantiates them (and actually the
> only way to do it, as we can't access them directly [right?]).
>
> 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.

MB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200526/c9f05900/attachment.html>