[PD-dev] Proposals for object categories
marius.schebella at gmail.com
Sat Feb 28 21:40:04 CET 2009
Luke Iannini wrote:
> On Fri, Feb 27, 2009 at 3:58 PM, Mathieu Bouchard <matju at artengine.ca> wrote:
>> On Fri, 27 Feb 2009, marius schebella wrote:
>>> Pd world series top 40
>>> frank's special blend
>>> other utilities
>>> objects that might crash
>>> the ones I almost never use
>>> not allowed during war
>> Other possible taxonomy: three categories total:
> Haha, as much as I would enjoy this...
> Do you or Marius have any concrete suggestions as to what wold be a
> better approach?
I still believe in a flat space class pool. all objects should live
inside the extra folder.
there may be two exceptions to that;
sometimes I want to load a library, and sometimes I want to make use of
name spaces. both cases are imho not related to a categorization system,
but to the general question "how can I identify every object in my
why/when do I want to load a library
* abbreviated objects (they're only available if the obj class was
* libraries/objects that provide additional features other than the
object itself (for example loaders, ..)
why/when do I want to make use of name spaces
* name clashes. from the past I think there are 10-20 external objects
that have the same name, but different functionality. and there are
hundreds of abstractions that have the same name as an external object.
> You must at least admit things could be better, no?
yes, right now objects are split up into "libraries" that are strongly
developer oriented, I think a pd-distro like pd-x should provide a
selection (all?) of these objects, unify them, document them and get rid
of the folder structure.
btw. one issue that is important (maybe not now, but some time in the
future) for the categorization discussion was not mentioned yet:
different libraries have different licenses. that would make some good
marius, who deleted 3 pages of additional text to make this email very
> I just took a look at Max/MSP and they have a nice tagging system, as
> well as an excellent configurable filter on their file browser that
> ends up being a pretty elegant solution to many of these problems.
> Perhaps going the route of adding parsable tags to object help patches
> (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd
> object)) that can then be read back by the help-browser is more what
> you're suggesting (I got that feeling from the threads you linked
> Mathieu). A good bit of work there though, and it doesn't do anything
> for namespace issues, just ease-of-discovery.
> But, I also do not think that the difficulties you guys are
> enumerating are enough to condemn the entire idea of organizing things
> more logically than by author. I can at least offer Python as example
> of an extremely well-organized set of libaries - I don't know the
> history of /how/ they came to be that way but i can easily "import
> functools, urllib, os, simpleosc, midi, Image, pickle", and it works
> phenomenally well.
>> _ _ __ ___ _____ ________ _____________ _____________________ ...
>> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
>> Pd-dev mailing list
>> Pd-dev at iem.at
More information about the Pd-dev