[L2Ork-dev] Encapsulation Ergonomics

[Guillem Bartrina]

Hello everyone,

I have been messing around with the back-end codebase the last few weeks 
and start figuring out how it works. Now I have an idea about how the 
class and message systems work, but there are still a lot more to be 
explored. The codebase isn't specially easy to read because of the 
existence of some cryptic variable and attribute names, the high amount 
of pointer arithmetic, the program's structure and functioning and 
finally because it is only partially commented. (In addition, I'm very 
busy due to university assignments)

I've already checked some of the points you told me in the last meeting 
and then Jonathan summarized. I've read the loader's abstractions module 
and I'm on the clone and declare ones.

----

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.

---

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?

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?

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.

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)?

- ...

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?]).

---

Finally about the timeline I proposed:

At first there isn't any major change but my  university changed the 
final exams period to June 12th-20th one week after the proposal 
submission deadline. Within this period I won't be able to be fully 
focused on Purr Data so I will try to distribute part of the work among 
the days before and after this period. I hope it isn't a major problem.

---

That's all I wanted to say for now.

This message is directed towards Matt (my mentor), but as I've seen that 
every member of the team is fully involved in the whole thing I'm 
posting this message on the mailing list. (If it isn't the right choice 
please let me know)

---

I look forward to all your thoughts, opinions or whatever.

Best,

Guillem