[PD] "list foreach"?

[Jonathan Wilkes]

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 at bar".  It's even possible to do that for methods of a class, which is what I've done with pdinfo/classinfo/canvasinfo/objectinfo.

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

-Jonathan



On Friday, October 10, 2014 4:19 AM, Chris McCormick <chris at mccormick.cx> wrote:
 


On 10/10/14 15:48, Jonathan Wilkes wrote:
> One last clarification-- I'm saying that I use the development process
> Chris outlines to do work on all flavors.  What frustrated me on this
> thread is the idea of a process where the community suggests or votes
> for certain features, and Miller adds them.  That model is too
> conservative-- it leads to fewer developers actually looking at the core
> code and (potentially) improving things.

Completely agree that would be too conservative. I don't think that's
how it works now either because other developer's patches do go into Pd.
For non-developer users I guess they have no other choice of course.

I am sorry if it sounded like I was telling you to do something that you
are already doing. That would be pretty annoying.

I think that for some features there is a case to be made for consensus
before development with so many actors and variants in the mix, but only
on features that we all think make sense to be shared by all flavours of
Pd. I think "list foreach" is a classic example of that type of thing
where it probably wouldn't be good for users if we had different
versions of this core object implemented.

Can you think of any others that are in Pd-l2ork right now that you feel
like probably should be in all versions of Pd?

I don't think it's reasonable for Pd-l2ork developers to feel like they
have to check every change with the community or with Miller. Happily,
that's not the case now and as a result you guys have been able to
innovate in very interesting directions.

There's probably a balance in there somewhere that lets users of
Pd-l2ork and users of Pd, extended, and libpd all win.


Cheers,

Chris.

-- 
http://mccormick.cx/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141010/99751740/attachment.html>