[PD] How's Pd limited?

Mon Feb 22 16:01:03 CET 2016

Or SC :)

2016-02-22 11:12 GMT-03:00 Matt Barber <brbrofsvl at gmail.com>:

> 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
>> them.
>> * 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>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160222/5c7afbd1/attachment-0001.html>