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.
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 <[email protected]> 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/
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
