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