[L2Ork-dev] Encapsulation Ergonomics

Jonathan Wilkes jon.w.wilkes at gmail.com
Sat May 23 17:48:37 EDT 2020


On Sat, May 23, 2020 at 1:03 PM Guillem Bartrina
<guillembartrina at gmail.com> wrote:
>
> 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)

Some of the code can and will be difficult to read. I got bit yesterday,
fixing a bug that led down a rabbit hole which almost certainly contains
more bugs (e.g., two different global variables with the same apparent
function, complete with code to keep them in sync plus a bugfix when
a completely unrelated startup flag causes them not to be...).
Luckily I was able to cordon off the original bug, so those other potential
issues can wait until later.

Let us know if we can help if anything is too cryptic or spaghetti-like.

Also note-- some of the code isn't legal C. For example, pd_typedmess
will invoke functions by casting to a function pointer with a different
signature than the original function. In fact looking back at it it appears
the signature differs not only by type but also by number of parameters.

(I imagine Zack may have already run into that particular issue-- IIRC
emscripten will refuse to compile those mismatched parameter counts.)

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

Pd Vanilla has its own separate codebase.

Purr Data still uses most of the Pd Vanilla backend code,
and we port in new Pd Vanilla features to Purr Data as time permits.

You can change the Purr Data core code to add new features and improvements.
We try to remain backwards-compatible and compatible with Pd Vanilla where
possible, while at the same time adding features which may not be available in
Pd Vanilla. You can add new methods, classes, and APIs to Purr Data to
create new
functionality. However, if you want to revise a currently existing
class, method, or
API-- take care so those revisions don't make unexpected changes for
the programs
that users already wrote using Purr Data. If we erroneously set Pi to
be 3 in 2009,
we need to ensure that 10 years of programs produced with Pd continue to sound
the way they should. (In fact there's a compatibility flag that can be
used to handle
such cases.)

In general I'd say the Purr Data policy is that if we can develop something in
Purr Data that works well with most of the design goals and constraints
of Pd Vanilla, we do it. By reading the code regarding classes and
message dispatching you can get a sense of that design we share with
Pd Vanilla.

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

Unfortunately I'm not familiar with the implementation of the clone_class,
so Matt should probably address this one.

>
> ---
>
> 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 that is. Probably out of your GSoC project this is the most
straightforward
part, but also a potentially big ergonomic improvement for users.

Probably the biggest challenge here is figuring out the necessary inlets,
outlets, and connections among them.

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

Suppose a user opens Purr Data and creates a new patch but hasn't
saved it.

Now they select some objects and use your feature to move that to
a new abstraction.

What happens? What directory shows up in the File Chooser?

That's just one edge use case I thought of.

>
> 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'll let Matt address your more substantial questions about the patch
definitions
first.

Best,
Jonathan

>
> ---
>
> I look forward to all your thoughts, opinions or whatever.
>
> Best,
>
> Guillem
>
>
>
>
>
>
>
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev


More information about the L2Ork-dev mailing list