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