[PD] How's Pd limited?
Niklas Reppel
nik at parkellipsen.de
Mon Feb 22 16:12:03 CET 2016
Well yeah lots of people jabber about how Max/MSP is an "industry
standard" and how badly documented Pd is (which might have been true 10
years ago,
but not today), and generally seem to be afraid of free software ...
incidentially, most of those use a Mac ;)
About the comparison to SC, well, different tools for different jobs, i
guess ?
On 22.02.2016 16:01, Alexandre Torres Porres wrote:
> Or SC :)
>
> 2016-02-22 11:12 GMT-03:00 Matt Barber <brbrofsvl at gmail.com
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/6fb74ebe/attachment-0001.html>
More information about the Pd-list
mailing list