[PD] How's Pd limited?
brbrofsvl at gmail.com
Mon Feb 22 15:12:45 CET 2016
Over the years, the most common complaint I've heard about Pd's limitations
is that it's not identical to Max/MSP.
On Mon, Feb 22, 2016 at 4:19 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).
> * 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.
> * 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.
> * Help files are *.pd which sounds neat at first, until you realize that
> they're not easily searchable and can't be viewed online.
> * 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.
> * 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.
> * 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.* 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
> * Want to print all messages flowing through a connection for debugging
> purposes? Remove the connection, then create a [t a a] object, then create
> a [print] object, then connect [print] to the second outlet, then connect
> [t a a] to the previous and next object (If you don't use the [trigger],
> messages will only be printed after they flow through the whole system).
> After you're done, delete the objects and re-create the connection. Not
> very convenient for quick debugging.
> * 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.
> * 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.
> * Standard GUI objects are ugly and have limited functionality.
> * 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.
> * *.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.
> * 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).
> * 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.
> These are just the first things that came to my mind...
> On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel <nik at parkellipsen.de>
>> 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 ->
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list