[PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

Christof Ressi christof.ressi at gmx.at
Wed Apr 6 12:17:07 CEST 2016


The difference is, OF has way more dependencies and therefore stuff to keep up do date than Pd, just because it deals a lot with graphics and video. 
However, a pure container class like ofPixels, well designed once, shouldn't need much of maintance. Except for updating everything to a newer versions of the underlying programming language (C++11) :-p. 

But since Pd is written in C, I can't believe that features like a sorting method for lists or a [atan2~] object will create any real maintainance overhead, even for a single core developer. 
Of course one should draw a line somewhere and I totally get you reasonings about keeping a core as compact as possible. 
But also a core should be as complete as possible, in a sense that you don't have to get an external library for really basic things which are offered by every decent programming language. 


What I'm really wondering: How is SuperCollider actually being maintained? The language core alone is just huge! 


> I feel like OF right now is where PD was circle early 2000s. 
It's, however, already an amazing piece of software! :-)


Gesendet: Mittwoch, 06. April 2016 um 06:48 Uhr
Von: "Dan Wilcox" <danomatika at gmail.com>
An: "Christof Ressi" <christof.ressi at gmx.at>
Cc: Pd-List <pd-list at lists.iem.at>
Betreff: Re: [PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

On Apr 5, 2016, at 5:59 PM, pd-list-request at lists.iem.at wrote: 
Joking aside, at least some externals that prove to be very useful or even fundamental (like zexy's sigops or [z~]) could find its way into the core now and then. To me, Pd vanilla seems to be overly conservative in this respect. On the other hand, I like that the set of objects is rather restricted, it's just about a handful of objects which I think are really missing and shouldn't require a user to get an external library. 

And when there are already good externals which do an important job, why not include them? For example, Pd vanilla got its own set of OSC objects recently (nice!), but they are rather awkward to use and have far less functionality then, for example, the mrpeach objects (Miller actually refers to them in the help patch).
 
The answer is maintainability:
 OF has 3 core members and 10+ affiliated core devs with commit access.
 
Pd has 1 core member with commit access.
 
I feel like OF right now is where PD was circle early 2000s. At some point it will stabilize since so many people rely on it and get tired of bugs and breaking changes introduced by *so* many commits by so many people. IMO the OF core is now way too large and parts of it should be spun off as addons.
 
It makes more sense to have a solid, slim core which you can add functionality to -> externals. This way, we get stability at a (small) loss of convenience by having to add an external. deken will make this relatively painless once the next Pd release comes out.
 

--------
Dan Wilcox
@danomatika[https://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 



More information about the Pd-list mailing list