<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yiv7506200475"><div id="yui_3_16_0_1_1456166530738_3385"><div id="yui_3_16_0_1_1456166530738_3384" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv7506200475"><div id="yiv7506200475yui_3_16_0_1_1456153888616_7249"><div id="yiv7506200475yui_3_16_0_1_1456153888616_7248" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv7506200475yui_3_16_0_1_1456153888616_7247">Hi Eugene,</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_7250">Great post!</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_7251"><br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_7252">I help develop pd-l2ork, and it addresses some of the points below. I recently got it building on OSX with most of the pd-extended libraries.<br clear="none"></div><div class="yiv7506200475qtdSeparateBR" id="yiv7506200475yui_3_16_0_1_1456153888616_7253"><br clear="none">I'll reply to each point below...<br clear="none"></div></div></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_7353"> <div id="yiv7506200475yui_3_16_0_1_1456153888616_3034" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div id="yiv7506200475yui_3_16_0_1_1456153888616_3033" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div class="yiv7506200475qtdSeparateBR" id="yiv7506200475yui_3_16_0_1_1456153888616_7352"><br clear="none"></div><div class="yiv7506200475yqt5538886981" id="yiv7506200475yqt88199"><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_3036"><font id="yiv7506200475yui_3_16_0_1_1456153888616_7950" face="Arial" size="2"> > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik <evgenius.lazarchik@gmail.com> wrote:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div class="yiv7506200475y_msg_container" id="yiv7506200475yui_3_16_0_1_1456153888616_3032"><div id="yiv7506200475"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3031"><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_3030"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3029"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3028"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3027"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3026"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3025"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3024"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3023"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3022">> Where do I start?<br clear="none"><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_3056"><div id="yui_3_16_0_1_1456166530738_7976">> * 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).</div><div><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8511">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 <br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8510">GOPs. Things get fixed there, and bug reports don't sit around for ten years.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8509"><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8512">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 <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_8508">a set of abstractions to faciliate connections using object/abstraction names instead of indices. But like GOP, dynamic patching is at its core pretty <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_8507">clunky so it would still be difficult to dynamically patch things (especially doing it live).<br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8420"><br clear="none"></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_3055"><div id="yiv7506200475yui_3_16_0_1_1456153888616_8231">> * 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.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8421"><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8422">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 <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_8551">use them. But it's definitely more complex than using list-abs or the newer array objects for single-dimensional arrays.<br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8423"><br clear="none"></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_3054"><div id="yiv7506200475yui_3_16_0_1_1456153888616_8424">> * 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.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8550"><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8548">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.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8549"><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8506">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 <br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8659">use that-- or any other design-- as a general replacement for wireless<br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8505"><br clear="none"></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_3053"><div id="yiv7506200475yui_3_16_0_1_1456153888616_8440">> * Help files are *.pd which sounds neat at first, until you realize that they're not easily searchable and can't be viewed online.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8658"><br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_8657">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 <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_8709">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<br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_8764">very much. But it's possible to do serious tweaks, save/load/ship an index, etc. if someone wants to take it on.<br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_8656"><br clear="none"></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_10759">> * 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.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_10760"><br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_10761">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 <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_14770">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 <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_14572">semicolons that aren't preceded by a slash.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_14769"><br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_14772">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 <br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_14773">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 <br clear="none"></div><div dir="ltr">in terms of the running instance and saving/loading patches).<br clear="none"></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_10762"><br clear="none"></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_14774">> * 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.</div><div id="yiv7506200475yui_3_16_0_1_1456153888616_14777"><br clear="none"></div><div dir="ltr" id="yiv7506200475yui_3_16_0_1_1456153888616_14776"><div id="yui_3_16_0_1_1456166530738_3450">I think Ivica added support for saving newlines inside comments (as above, it uses a hack to deal with special characters). But they still get parsed-- <br></div><div dir="ltr" id="yui_3_16_0_1_1456166530738_3449">that's bad, although Pd isn't the only language that does that.<br></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_14775"><br clear="none"></div></div><div id="yui_3_16_0_1_1456166530738_3394">> * 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.</div><div id="yui_3_16_0_1_1456166530738_3396"><br clear="none"></div><div id="yui_3_16_0_1_1456166530738_3395"><div id="yui_3_16_0_1_1456166530738_3454" dir="ltr">This is a hard problem. The only solution I know of is to draw an extra border in editmode showing the maximum width and height for the object <br></div><div id="yui_3_16_0_1_1456166530738_3478" dir="ltr">at the given canvas font size.</div><div id="yui_3_16_0_1_1456166530738_10284" dir="ltr"><br></div><div dir="ltr">My hypothesis is that any spec you come up with for fixing this will cause more problems than it solves. And I see complaints like the one you've <br></div><div dir="ltr">raised here in other GUI toolkits/APIs like Qt and HTML5, with no obvious solutions.<br></div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd61149"><div id="yui_3_16_0_1_1456166530738_3451"><br clear="none"></div><div id="yui_3_16_0_1_1456166530738_3452"><div id="yui_3_16_0_1_1456166530738_5329">> * 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.</div><div><br></div><div id="yui_3_16_0_1_1456166530738_5376">Yeah, that's bad. But at least in Pd-l2ork you can a) auto-connect one object to many, b) auto-connect many to one, and c) auto-connect many <br></div><div id="yui_3_16_0_1_1456166530738_5378">to many.<br></div><div id="yui_3_16_0_1_1456166530738_5377"><br></div></div></div></div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd21489"><div>> * Want to print all messages flowing through a connection for debugging purposes?</div><div id="yui_3_16_0_1_1456166530738_5380"><br></div><div>Use the cord inspector, aka magic glass, available in the last version of Pd-extended as well as Pd-l2ork.<br></div><div id="yui_3_16_0_1_1456166530738_5382"><br></div><div id="yui_3_16_0_1_1456166530738_5478">> * 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.</div><div id="yui_3_16_0_1_1456166530738_7975"><br></div><div dir="ltr" id="yui_3_16_0_1_1456166530738_5479">That's true, though it isn't a technical problem.<br></div><div id="yui_3_16_0_1_1456166530738_7977"><br></div></div></div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd51781"><div id="yui_3_16_0_1_1456166530738_5672">> * 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.</div><div id="yui_3_16_0_1_1456166530738_5671"><br></div><div dir="ltr" id="yui_3_16_0_1_1456166530738_5670">I know a lot of people want segmented patch cords. I'm pretty happy with Pd-l2ork's bezier cords myself, but if someone has enough interest to <br></div><div dir="ltr">implement and test Max-style segmented cords I wouldn't dig my heels in against them.<br></div><div id="yui_3_16_0_1_1456166530738_5519"><br></div></div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd24500"><div id="yui_3_16_0_1_1456166530738_8162">> * Standard GUI objects are ugly and have limited functionality.</div><div id="yui_3_16_0_1_1456166530738_5708"><br></div><div id="yui_3_16_0_1_1456166530738_5722">Yes. Just curious-- what's the most critical functionality you feel is missing?<br></div><div id="yui_3_16_0_1_1456166530738_5709"><br></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_3048"><div id="yiv7506200475yui_3_16_0_1_1456153888616_3047"><div id="yui_3_16_0_1_1456166530738_5480"><div id="yui_3_16_0_1_1456166530738_7957">> * 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.</div><div id="yui_3_16_0_1_1456166530738_7958"><br></div><div id="yui_3_16_0_1_1456166530738_7959">What are the practical limitations of the higher memory use in these cases? You're still going to have the same message passing overhead.</div><div id="yui_3_16_0_1_1456166530738_7960"><br></div></div><div id="yui_3_16_0_1_1456166530738_7962"><div id="yui_3_16_0_1_1456166530738_7961">> * *.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.</div><div id="yui_3_16_0_1_1456166530738_7963"><br></div><div id="yui_3_16_0_1_1456166530738_7964">Also true, but isn't the same for all dataflow/flow-based languages?</div><div id="yui_3_16_0_1_1456166530738_8326"><br></div></div><div id="yiv7506200475yui_3_16_0_1_1456153888616_3046"><div id="yui_3_16_0_1_1456166530738_7965">> * 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).</div><div id="yui_3_16_0_1_1456166530738_7966"><br></div><div id="yui_3_16_0_1_1456166530738_8327">This is a problem of mentoring, or lack of it. All I can say is that Ivica fixed all the bugs I threw at him wrt Pd-l2ork, and now I try to do the same with <br></div><div id="yui_3_16_0_1_1456166530738_7967">the work I do on Pd-l2ork.</div><div id="yui_3_16_0_1_1456166530738_7968"><br></div></div><div id="yui_3_16_0_1_1456166530738_5723"><div id="yui_3_16_0_1_1456166530738_7969">> * 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.</div><div id="yui_3_16_0_1_1456166530738_8333"><br></div><div id="yui_3_16_0_1_1456166530738_7974">What's the alternative? Also, note that there is a Pure Data forum for general discussions, too.<br></div><br clear="none"></div><div id="yui_3_16_0_1_1456166530738_7583"><div id="yui_3_16_0_1_1456166530738_7973">> These are just the first things that came to my mind...</div><div id="yui_3_16_0_1_1456166530738_7970"><br></div><div id="yui_3_16_0_1_1456166530738_7971">They are certainly helpful, and I'd encourage you to keep them coming. I can't speak for the rest of the community, but feedback like this <br></div><div id="yui_3_16_0_1_1456166530738_10287" dir="ltr">is worth its weight in gold. And at least on Pd-l2ork, it _can_ affect the future path the software takes.</div><div id="yui_3_16_0_1_1456166530738_10286" dir="ltr"><br></div><div id="yui_3_16_0_1_1456166530738_10285" dir="ltr">-Jonathan<br></div></div></div></div><div class="yiv7506200475yqt1142049840" id="yiv7506200475yqt63648"><div class="yiv7506200475gmail_extra" id="yiv7506200475yui_3_16_0_1_1456153888616_3044"><br clear="none"><div class="yiv7506200475gmail_quote" id="yiv7506200475yui_3_16_0_1_1456153888616_3043">On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:nik@parkellipsen.de" target="_blank" href="mailto:nik@parkellipsen.de">nik@parkellipsen.de</a>></span> wrote:<br clear="none"><blockquote class="yiv7506200475gmail_quote" id="yiv7506200475yui_3_16_0_1_1456153888616_3042" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hmm, i always thought that the dynamic creation and destruction of sound sources (oscillators etc.) pretty inconvenient in PD,<br clear="none">
compared to a source-code based approach.<br clear="none">
<br clear="none">
Maybe i missed some developments here, but the last time i checked (a year ago maybe), this was clearly quite<br clear="none">
a hassle, even though i know it's possible.<br clear="none">
<div class="yiv7506200475HOEnZb" id="yiv7506200475yui_3_16_0_1_1456153888616_3041"><div class="yiv7506200475h5" id="yiv7506200475yui_3_16_0_1_1456153888616_3040"><br clear="none">
<br clear="none">
On Mon, Feb 22, 2016 at 03:49:43AM +0200, Matti Viljamaa wrote:<br clear="none">
> Perhaps a bit of broad question, but I find it interesting in order to speculate about future additions.<br clear="none">
><br clear="none">
> How do you think Pure Data is limited?<br clear="none">
> _______________________________________________<br clear="none">
> <a id="yui_3_16_0_1_1456166530738_10315" rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">
> UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" id="yiv7506200475yui_3_16_0_1_1456153888616_3045" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
<a id="yui_3_16_0_1_1456166530738_10316" rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
</div></div></blockquote></div><br clear="none"></div></div></div></div></div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd37481"><br clear="none"><div class="yiv7506200475yqt1142049840" id="yiv7506200475yqt32540">_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></div></div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd64511"> </div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd66805"> </div></div><div class="yiv7506200475yqt4652426752" id="yiv7506200475yqtfd94357"> </div></div></div></div></div></div></body></html>