[L2Ork-dev] Encapsulation Ergonomics
guillembartrina at gmail.com
Sat May 23 13:03:29 EDT 2020
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
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
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
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
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.
More information about the L2Ork-dev