[PD] representning classes and selectors in the wiki

IOhannes m zmoelnig zmoelnig at iem.at
Wed Sep 12 19:51:58 CEST 2007


Roman Haefeli wrote:
> hi marius, hi iohannes
>
> 
> however, this is actually a different story, but probably affects the
> way we want to implement the wiki. since there _are_ incompatibilites
> between pd-vanilla/original libs and pd-extended, i vehemently propose
> to decide which route to follow for the database: the
> 'pd-vanilla/externals' way or the 'pd-extended' way. let's also face who
> is actually addressed with this database. one of its goals is to have
> all information about objects available at one place, which is, i think,
> fairly essential for people, who are new to pd and want to explore all
> facets of pd. i also believe, that most of these people will use
> pd-extended, since it is by far the easiest way to get 'just
> everything'. taking into account all these points, i strongly believe,
> that it would be the best way to reflect the pd-extended topology in the
> database, none the less just because people, who compile pd and
> externals themselves could live more easily with incostistencies between
> their pd installation and the database than less experienced pd users.

fair enough

but what about all those libraries that are not in pd-extended?
do they have to stay outside the wiki until they are extendified?

> 
> why making it flat und having to deal with nameconflicts, when the
> libdir was introduced in order to just avoid that?
> 
> yo, i hope i didn't bring something up, that has been discussed and
> defined before already, since i missed the major part of the pd-doc
> meeting.
> 

i haven't even been at the pd-doc meeting and still have to have my say.
anyhow, thanks for the sum-up.

fmasdr.
IOhannes




More information about the Pd-list mailing list