<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>The only case to be made is for development, with the imperative, "develop." It's quite trivial to post a message to the console for a new class that says "version 0.1" and/or "not stable yet" and/or "send feedback to foo@bar". It's even possible to do that for methods of a class, which is what I've done with pdinfo/classinfo/canvasinfo/objectinfo.</span><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div
style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>If you have access to a Linux box, I highly recommend downloading the source for Pd-l2ork from git, compiling, and giving it a try. There are too many generally-applicable features to list here, but here's what comes to mind: infinite undo, object z-order control from "Edit" menu and right-click canvas menu, colors other than black for garray trace, better prefs dialog, presets that handle abstractions without the need for $0, resize anchor for iemguis and red gop rect, hyperlinked errors in the console, Max-style [trigger b 42], [select] right inlet can receive symbol or float, PDDP documentation, _natural_ _language_ _search_ _engine_, cross-referenced tutorials, hyperlinks, sending a single "canvas move" instruction to the gui when displacing a selection of
objects, not deleting/redrawing the entire garray when the user displaces it, (some) standard key bindings for editing inside an object box, multi-connect logic, a better "Tidy Up", displace anchor for iemgui labels, objects for canvas/object/class/pd-instance introspection...</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>-Jonathan<br></span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family:
HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font face="Arial" size="2"> On Friday, October 10, 2014 4:19 AM, Chris McCormick <chris@mccormick.cx> wrote:<br> </font> </div> <br><br> <div class="y_msg_container">On 10/10/14 15:48, Jonathan Wilkes wrote:<br clear="none">> One last clarification-- I'm saying that I use the development process<br clear="none">> Chris outlines to do work on all flavors. What frustrated me on this<br clear="none">> thread is the idea of a process where the community suggests or votes<br clear="none">> for certain features, and Miller adds them. That model is too<br clear="none">> conservative-- it leads to fewer developers actually looking at the core<br clear="none">> code and (potentially) improving things.<br clear="none"><br clear="none">Completely agree that would be too conservative. I don't think that's<br
clear="none">how it works now either because other developer's patches do go into Pd.<br clear="none">For non-developer users I guess they have no other choice of course.<br clear="none"><br clear="none">I am sorry if it sounded like I was telling you to do something that you<br clear="none">are already doing. That would be pretty annoying.<br clear="none"><br clear="none">I think that for some features there is a case to be made for consensus<br clear="none">before development with so many actors and variants in the mix, but only<br clear="none">on features that we all think make sense to be shared by all flavours of<br clear="none">Pd. I think "list foreach" is a classic example of that type of thing<br clear="none">where it probably wouldn't be good for users if we had different<br clear="none">versions of this core object implemented.<br clear="none"><br clear="none">Can you think of any others that are in Pd-l2ork right now that you feel<br
clear="none">like probably should be in all versions of Pd?<br clear="none"><br clear="none">I don't think it's reasonable for Pd-l2ork developers to feel like they<br clear="none">have to check every change with the community or with Miller. Happily,<br clear="none">that's not the case now and as a result you guys have been able to<br clear="none">innovate in very interesting directions.<br clear="none"><br clear="none">There's probably a balance in there somewhere that lets users of<br clear="none">Pd-l2ork and users of Pd, extended, and libpd all win.<div class="yqt0721514692" id="yqtfd58954"><br clear="none"><br clear="none">Cheers,<br clear="none"><br clear="none">Chris.<br clear="none"><br clear="none">-- <br clear="none"><a href="" class="removed-link" shape="rect" target="_blank">http://mccormick.cx/</a><br clear="none"></div><br><br></div> </div> </div> </div> </div></body></html>