[PD] How's Pd limited?

[Roman Haefeli]

On Mon, 2016-02-22 at 01:19 -0800, Eugene Lazarchik wrote:
> Where do I start?

Thanks. That is a pretty comprehensive list, though I do not agree with
all your points (ugly look, mailing list, big patches become unreadable
fast). For me the most important point is still missing.

* Since Pure Data aims to be a realtime / live application, I am missing
most that I cannot do some actions without interrupting audio.
Everything that touches the DSP graph is a no-go. There's a way around
many things that touch DSP graph (never resize arrays used in DSP, for
instance). But not being able load patches without interrupting audio is
the most limiting factor for me. 

* The world of CPUs has shifted focus from single-threading performance
to many cores and power efficiency. It seems it's getting harder finding
a device with a single-threading performance as good as my 8-year old
laptop. And I'm easily saturating that one with my Pd stuff. What am I
going to do when it dies? I'd love if Pd would provide some true
multi-threading (not like [pd~] which is tightly coupled to its parent).

Roman


> * 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.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160223/7469b4c9/attachment.sig>