[PD] How's Pd limited?
Niklas Reppel
nik at parkellipsen.de
Mon Feb 22 22:13:28 CET 2016
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
More information about the Pd-list
mailing list