Re: [PD] How's Pd limited?

[Eugene Lazarchik]

Thanks for replying, Jonathan.

If Pd-l2ork starts to supports Mac I'll seriously consider switching to it.
Sounds like many of the issues and inconveniences are fixed there. Let me
reply to your questions.

> * Standard GUI objects are ugly and have limited functionality.
>
> Yes.  Just curious-- what's the most critical functionality you feel is
> missing?
>

I don't recall all of my frustrations with the GUI objects, I just remember
there were many. But let me try.
 * A button object. You know, a rectangle with a piece of text that can be
clicked to generate a bang. Usually people put a bang next to a comment,
but it takes more space. I've also seen people implementing load and save
buttons by putting "L" and "S" inside bangs. It looks really ugly and is
hard to read, especially when the bang is small. When I first saw the
browser 
abstraction from the mmb library I was very curious how it works. Turns
out, it uses sliders! They send messages when are clicked and slider
position indicator can be hidden by choosing colors in the properties menu.
I think this is a great illustration to how often PD makes us create
hacks/workarounds instead of having a nice straightforward solution.
 * Ability to remove "dented" corners (symbolbox and numberbox) and the
triangle from number2, as well as hide the border completely. They can be
helpful when doing quick prototyping but when I'm building a nice GUI, I
often don't want to see them.
 * A text box that visually indicates that it has focus and stuff is
getting entered. Even better: show a cursor, allow to move it around and
select and copy/paste text.
 * Some kind of API to determine mouse coordinates _relative to the GOP_.
Currently there seems to be no way of, say, building a menu abstraction
that will highlight menu items when mouse cursor hovers over them (it
should work regardless of how many subpatches deep it's situated and which
of the parent subpatches is currently open).
 * Drop-down list and selectbox, working out of the box, no external
libraries.
 * Ability to edit subpatch/abstraction arguments from the properties menu
when subpatch/abstraction is in GOP mode with hidden arguments. Currently
one has to disable GOP, edit the arguments, reenable GOP again.
 * Ability to hide inlets/outlets when using GOP. The little boxes are
often distracting and they take additional space. Currently a similar
effect can be achieved by placing a canvas of the same size as the GOP area
that covers it.


> > * There's no good support for the concept of functions/procedures. Let's
> say we need to take some input, do some transformations and produce output,
> and we need to do that in multiple places in our patch. We can copy the
> objects but that will make the patch use more memory and there will be no
> code reuse. Another way is to make that an abstraction, but it's silly to
> make abstractions for every little thing that we need in 2 places. Also,
> instantiating 2 abstractions still uses more memory. We can try reusing the
> same code but we'll have to make multiple output connections so we'll need
> proper routing in order to figure out where to send the result. I made an
> abstraction to simplify that but this should be a standard feature of PD.
>
> What are the practical limitations of the higher memory use in these
> cases?  You're still going to have the same message passing overhead.
>

I don't know too much about how PD works internally but I imagine it
probably maps all objects into some data structure in memory and then
passes messages around by going from one object to another. The more
objects is there in the patch and all subpatches, the more memory it'll
take. It's probably a very small amount of memory per object, but
theoretically it can add up (if certain abstractions are used multiple
times in other abstractions, which are used multiple times in other
abstractions, etc.), especially on mobile platforms. Maybe the additional
memory usage is always very tiny, I don't know. But it feels weird to be
wasteful.

Anyway, there's other use cases for this concept. Imagine object [pd A]
that is a storage of some type. When banged on the inlet it sends the
storage contents to the outlet. Objects [B], [C] and [D] need to be able to
query the contents of object [A]'s storage. We can connect their outlets to
[A] so that they can send a bang to it but how do we route the output? We
don't want [C] and [D] to receive the output when [B] sends a bang to [A].
We can use spigots or store the output in intermediate objects ([float],
[symbol], [list]) but it all complicates the patch and makes it less
readable. I created a [func] abstraction that can be used like this:

[inlet from B]
|
[func]x[pd A]<= A may be connected to other objects but we'll
ignore all output from it unless a message from B initiated it
|
[outlet to B]

It ignores all input from the right inlet unless a 

Re: [PD] How's Pd limited?

[Eugene Lazarchik]

I consider sends and receives evil. They're similar to global variables or
goto statements in general purpose programming languages.

When you see a receive object, it's not obvious where all corresponding
sends may be. As opposed to simply following where the cords go.

Also, consider a subpatch (or abstraction), with certain cords connected to
it. In a way the inlets and outlets describe how this object can be used:
it can receive certain messages through inlets and then send output to the
outlets. But if there's sends and receives inside, it becomes much harder
to track what the object may do.

In regards to the screenshot: it could be simplified by putting stuff into
subpatches. However, even when there's only a couple of objects on a
subpatch, the cords can still cross the objects if there's no way to
segment them. Typical reasons include long objects ([pd
$0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this
and that], etc.). Also it's hard to avoid a mess without segmenting if
there's a lot of feedback connections (when A's output is connected to B
but also B's output is connected to A).

Also, moving functionality in a subpatch usually should only be done when
there's something common between the objects inside and they implement a
relatively siloed functionality. Otherwise it may be hard to understand
what the subpatch is doing and the reader will have to constantly switch
between the parent and the subpatch to understand how they work together.

On Mon, Feb 22, 2016 at 12:25 PM, Matt Barber <brbrof...@gmail.com> wrote:

> I've said this before, but I think there are very good reasons not to ever
> include segmented patch cords (although hideable patch cords would be even
> worse). These two features are responsible for some of the very worst
> patching habits in Max/MSP. Have you ever been called on to run someone's
> patch, and you need to tweak something for your specific audio setup or fix
> a bug or whatever, and when you open it you get something that looks like
> this (one of the first "max patch" results on google image search):
>
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg
>
> If you can't bend the cords there's much less of a temptation to make
> these kinds of can-of-worms patches, and more of an incentive to use
> send/receive when you need to get a value into an inconvenient place.
> There's also an incentive to make things more modular, which is usually far
> easier to debug than a huge sprawling patch. So while I can see where
> they'd be very useful if used judiciously, as someone who often has to
> operate someone else's patches, I'm very hesitant.
>
>
> On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
>> Hi Eugene,
>> Great post!
>>
>> I help develop pd-l2ork, and it addresses some of the points below.  I
>> recently got it building on OSX with most of the pd-extended libraries.
>>
>> I'll reply to each point below...
>>
>> > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik <
>> evgenius.lazarc...@gmail.com> wrote:
>>
>>
>> > Where do I start?
>>
>> > * Dynamic patching is officially not supported and bug/feature requests
>> get ignored. I had to jump through a lot of hoops to use dynamic patching
>> with GOP but I discovered a bunch of weird issues with subpatches not
>> getting redrawn and connectors left hanging after object deletion. Had to
>> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
>> Sending loadbangs to dynamically created objects is a pain, as well as
>> trying to dynamically connect them to something (most examples of using the
>> "connect" message use hardcoded object ID's).
>>
>> GOP with dynamic patching is certainly tricky-- I find it way too
>> complicated to be generally useful.  However, Pd-l2ork should work without
>> bugs with
>> GOPs.  Things get fixed there, and bug reports don't sit around for ten
>> years.
>>
>> As far as connect messages-- I have exposed the canvas "find" method
>> inside an object called [canvasinfo] in pd-l2ork.  It would be possible to
>> write
>> a set of abstractions to faciliate connections using object/abstraction
>> names instead of indices.  But like GOP, dynamic patching is at its core
>> pretty
>> clunky so it would still be difficult to dynamically patch things
>> (especially doing it live).
>>
>> > * Support for lists is quite limited. Wanna create a multidimentional
>> array? Build your own. Want a hash map? Build your own. Luckily there's
>> list-abs but it's weird that such basic functionality (that's present in
>> most progra