[PD] How's Pd limited?

[Niklas Reppel]

Hmm i'd say there's no way to force people to employ transparent, modular software 
design as long as you want to keep the language (whether it's patcher- or code-based)
somewhat flexible and powerful ... 

On Mon, Feb 22, 2016 at 09:03:16PM +0000, Jonathan Wilkes via Pd-list wrote:
> There are plenty of Pd patches just as unreadable.
> 
> When a large number of users are getting value out of code that unreadable, we
> need to ask more fundamental questions than
> whether the visual noise includes more or fewer right angles.
> 
> -Jonathan
> 
> 
> 
> On Monday, February 22, 2016 3:25 PM, Matt Barber <brbrofsvl at 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 at 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.lazarchik at 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 programming languages) is not a core language feature.
> 
>     Data structures have support for multi-dimensional arrays.  In Pd-l2ork you
>     can create a scalar in an object box which makes it slightly easier to
>     use them.  But it's definitely more complex than using list-abs or the
>     newer array objects for single-dimensional arrays.
> 
>     > * Sends and receives are global which creates a potential for conflicts.
>     $0 can be used to avoid that but it looks ugly and many libraries, patches,
>     and I think even help files, don't use it.
> 
>     I agree that $0 is ugly.  I've got some locality using data structures with
>     a "canvas" field in upcoming Pd-l2ork release, but it's still very
>     experimental.
> 
>     Pd-l2ork has [preset_hub] and [preset_node] which handle locality without
>     $0.  It works quite well, but it would be an _enormous_ undertaking to
>     use that-- or any other design-- as a general replacement for wireless
> 
>     > * Help files are *.pd which sounds neat at first, until you realize that
>     they're not easily searchable and can't be viewed online.
> 
>     They are searchable in Pd-l2ork, as well as the last version of Pd-extended
>     (I think).  In the upcoming version of Pd-l2ork the help browser indexes
>     the
>     doc folder in less than a second.  I'm just indexing the keywords in [pd
>     META]-- it could index full text too but that turns out not to improve the
>     results
>     very much.  But it's possible to do serious tweaks, save/load/ship an
>     index, etc. if someone wants to take it on.
> 
>     > * Bugs and weird behavior when handling special characters. There's no
>     consistent way of escaping them. Sometimes characters disappear when saving
>     and loading a patch.
> 
>     I gutted all the tcl commands from the GUI calls for Pd-l2ork, so
>     theoretically it should be way easier to handle special characters now. 
>     But I have to
>     admit I'm using some low value ASCII code to delimit messages to the GUI. 
>     It's just way easier to split on a single byte as opposed to, say, the
>     semicolons that aren't preceded by a slash.
> 
>     Still, there is a lot of work to make sure special characters and spaces
>     get saved correctly within Pd.  It needs a lot of testing by a developer
>     who
>     knows all the ins and outs of how to read/write/revise a parser, plus
>     knowing exactly how those changes will affect past and future Pd patches
>     (both
>     in terms of the running instance and saving/loading patches).
> 
>     > * Limited support for comments. Special characters are not allowed
>     (really? these are comments!). Automatic line wrapping doesn't work well
>     since after saving/loading a patch often changes how text is broken into
>     lines. So I have to put each line as a separate comment.
> 
>     I think Ivica added support for saving newlines inside comments (as above,
>     it uses a hack to deal with special characters).  But they still get
>     parsed--
>     that's bad, although Pd isn't the only language that does that.
> 
>     > * Dependence on font sizes. By default object boxes scale automatically
>     depending on the text inside. When you add more text, all inlets/outlets
>     move. I installed a different version of PD and font size is slightly
>     different and all objects are of a different size now.
> 
>     This is a hard problem. The only solution I know of is to draw an extra
>     border in editmode showing the maximum width and height for the object
>     at the given canvas font size.
> 
>     My hypothesis is that any spec you come up with for fixing this will cause
>     more problems than it solves.  And I see complaints like the one you've
>     raised here in other GUI toolkits/APIs like Qt and HTML5, with no obvious
>     solutions.
> 
>     > * Want to add an outlet to the beginning of a trigger object? Enjoy
>     disconnecting and connecting all other outlets since there's no way of
>     automatically move them.
> 
>     Yeah, that's bad.  But at least in Pd-l2ork you can a) auto-connect one
>     object to many, b) auto-connect many to one, and c) auto-connect many
>     to many.
> 
>     > * Want to print all messages flowing through a connection for debugging
>     purposes?
> 
>     Use the cord inspector, aka magic glass, available in the last version of
>     Pd-extended as well as Pd-l2ork.
>    
>     > * Vanilla provides only minimal functionality while most of the
>     convenient objects are supposed to come from external libraries. There's
>     multiple issues with that. First one is that libraries are less
>     standardized and consistent. They have different approaches, sometimes
>     duplicate each other, use different conventions for naming, inlets/outlets,
>     etc. Second issue is that libraries often become dead/unmaintained.
> 
>     That's true, though it isn't a technical problem.
> 
>     > * Big patches/abstractions become unreadable really fast. Connectors are
>     always straight lines and there's no support for dummy intermediate
>     "points" for connecting stuff. I use [t a] and [+~] for these purposes but
>     it'd be nice to have native support for this.
> 
>     I know a lot of people want segmented patch cords.  I'm pretty happy with
>     Pd-l2ork's bezier cords myself, but if someone has enough interest to
>     implement and test Max-style segmented cords I wouldn't dig my heels in
>     against them.
> 
>     > * Standard GUI objects are ugly and have limited functionality.
> 
>     Yes.  Just curious-- what's the most critical functionality you feel is
>     missing?
> 
>     > * 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.
> 
>     > * *.pd format is not very friendly to Git. Try viewing diffs and
>     resolving merge conflicts. Moving a subpatch on the screen causes different
>     coordinates to be saved in the file, often resulting in conflicts. Cutting
>     and pasting renumbers all objects and connections. This makes using
>     branches and working on the same files impractical.
> 
>     Also true, but isn't the same for all dataflow/flow-based languages?
> 
>     > * PD seems to be maintained by only a handful of people and new features/
>     bug fixes are rarely released. I used to code in C and was thinking of
>     contributing but I found no good guide for new contributors. I wasn't even
>     able to compile PD on my Mac (there's multiple build scripts in the sources
>     but none of them work). I'm also not sure what the testing process should
>     be (to make sure I'm not breaking any existing functionality or support for
>     operating systems or devices).
> 
>     This is a problem of mentoring, or lack of it.  All I can say is that Ivica
>     fixed all the bugs I threw at him wrt Pd-l2ork, and now I try to do the
>     same with
>     the work I do on Pd-l2ork.
> 
>     > * PD community uses mailing lists for communications, haha. In order to
>     find useful information I have to view one message per page, with tons of
>     distracting quotes from previous messages.
> 
>     What's the alternative?  Also, note that there is a Pure Data forum for
>     general discussions, too.
> 
>     > These are just the first things that came to my mind...
> 
>     They are certainly helpful, and I'd encourage you to keep them coming.  I
>     can't speak for the rest of the community, but feedback like this
>     is worth its weight in gold.  And at least on Pd-l2ork, it _can_ affect the
>     future path the software takes.
>    
>     -Jonathan
>    
>     On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel <nik at parkellipsen.de> wrote:
> 
>         Hmm, i always thought that the dynamic creation and destruction of
>         sound sources (oscillators etc.) pretty inconvenient in PD,
>         compared to a source-code based approach.
> 
>         Maybe i missed some developments here, but the last time i checked (a
>         year ago maybe), this was clearly quite
>         a hassle, even though i know it's possible.
> 
> 
>         On Mon, Feb 22, 2016 at 03:49:43AM +0200, Matti Viljamaa wrote:
>         > Perhaps a bit of broad question, but I find it interesting in order
>         to speculate about future additions.
>         >
>         > How do you think Pure Data is limited?
>         > _______________________________________________
>         > Pd-list at lists.iem.at mailing list
>         > UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>         listinfo/pd-list
> 
>         _______________________________________________
>         Pd-list at lists.iem.at mailing list
>         UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>         listinfo/pd-list
> 
> 
>    
>     _______________________________________________
>     Pd-list at lists.iem.at mailing list
>     UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/
>     pd-list
> 
> 
> 
>     _______________________________________________
>     Pd-list at lists.iem.at mailing list
>     UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/
>     pd-list
> 
> 
> 
> 
> 

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list