It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some french PDers the following features:
a lexicon-dictionary about objects/externals/abstractions ( Done)
a category search portal ( one of the most
important feature for pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search: PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add /pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend ( fiction...)
- multilingual structure as Wikipedia ( very
important for educational uses in the world where people will stay with commercial software just for this reason ( France for example)) (Done)
future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches (
parsing of the patch code to create an image of the patch, server side) and downloading text patches from PDpedia
- Pdpedia database embedded with PD extended (
when completed) for offline consulting
- in PD: a contextual help with access to the
related pdpedia page (in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3, Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize PDpedia Parties:
It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5 per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta atmosphere
I have also suggested that all PD teachers should give time in their workshops for the students to document on PDpedia the object they are discovering.
Of course, PDpedia is a long term project. There are also many initiatives like the great FLOSSmanuals, or videopedia to produce tutorials.
Because of the 2500 objects/elements, the PDpedia is more on the encyclopedic aspect. 2500 objects and more could be completed in many languages in five years, if the community understand how politically important is to help newbies to use such tools with documentation facilities. Documenting is not sometimes very sexy, that's why I suggest to organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not do it at this time), for an antispam system with a captcha or similar stuff.
JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see that this problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing out well? I believe "someone" could also direct how things are going, and that a main team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful.
Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
There are lots of good ideas worth trying. We've talked about it a
lot, we just need someone to take charge of it. I am just too
overloaded to handle pdpedia on top of everything else. Who wants to
own it?
.hc
On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some
french PDers the following features:
a lexicon-dictionary about objects/externals/abstractions ( Done)
a category search portal ( one of the most important feature for
pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search:
PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add / pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend
( fiction...)
- multilingual structure as Wikipedia ( very important for
educational uses in the world where people will stay with commercial
software just for this reason ( France for example)) (Done)future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches ( parsing of the patch
code to create an image of the patch, server side) and downloading
text patches from PDpedia
- Pdpedia database embedded with PD extended ( when completed) for
offline consulting
- in PD: a contextual help with access to the related pdpedia page
(in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links
to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3,
Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize
PDpedia Parties:It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5
per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a
limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta
atmosphereI have also suggested that all PD teachers should give time in their
workshops for the students to document on PDpedia the object they
are discovering.
Of course, PDpedia is a long term project. There are also many
initiatives like the great FLOSSmanuals, or videopedia to produce
tutorials.Because of the 2500 objects/elements, the PDpedia is more on the
encyclopedic aspect. 2500 objects and more could be completed in many languages in five
years, if the community understand how politically important is to
help newbies to use such tools with documentation facilities.
Documenting is not sometimes very sexy, that's why I suggest to
organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not
do it at this time), for an antispam system with a captcha or
similar stuff.JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see
that this
problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing
out well? I
believe "someone" could also direct how things are going, and
that a main
team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't
find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much
more useful.Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
hi folks,
i am somewhat interested in investing some time in pdpedia, but i have a few concerns with mediawiki as a container for pd related data.
obviously mediawiki is an excellent versioning platform and has a strong following for many technical wiki's in the open-source community. i think its an excellent format for plain text information, which takes the form of tutorials/howto/guide, but as an object reference it has a limited scope.
this is especially the case when attempting to pull that information into another format (ie.. not html). anything pulled off the server using the api needs to be parsed to be made useful in another context, and in many cases reparsed to pick out the meta-references, and this is without getting to the content which is often categorised in an entirely different format.
i have previously invested a fair chunk of time in refencing objects in a sql database, while my work was not designed with versioning in mind, it was designed to be utilised by pd (dd was the projected environment) or pd libs internally, or in other formats like a postscript reference or generating pddp formatted helpfiles. i have recently started picking up the pieces of this project (which i had ceased with the initial announcement of pdpedia).
anyhow, what i am beginning to see a need for is an infrastructure like mediawiki which stores pd files rather than plain-text. think of it like a categorised + tagged svn. this would be a place where people can upload files relating to pd use, examples of usage, methods of interfacing and anything else that gets passed around on this mailing list. keeping with the same wiki format of edits by anyone, and versioning each subsequent edit. then in a similar method to mediawiki api calls, pd internally could request a list of articles (pd-patches) and dynamically retrieve requested articles from the pdwiki. thus making the system much more usable within the pd environment.
i think the benefit of this would be quite obvious to pd-users, as it has been stated many times by numerous people that a plain text wiki reference doesn't really make much sense without the interactive characteristics of an actual patch.
this is something i would happily put energies into development, and
in many ways have already started. i will likely end up building
something that works in this way anyway, so please throw in
suggestions, before i get carried away ;)
ciao,
dmotd
On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote:
There are lots of good ideas worth trying. We've talked about it a lot, we just need someone to take charge of it. I am just too overloaded to handle pdpedia on top of everything else. Who wants to own it?
.hc
On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some french PDers the following features:
- a lexicon-dictionary about objects/externals/abstractions (
Done)
- a category search portal ( one of the most important feature
for pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search: PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add / pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend ( fiction...)
- multilingual structure as Wikipedia ( very important for
educational uses in the world where people will stay with commercial software just for this reason ( France for example)) (Done)
future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches ( parsing of the
patch code to create an image of the patch, server side) and downloading text patches from PDpedia
- Pdpedia database embedded with PD extended ( when completed)
for offline consulting
- in PD: a contextual help with access to the related pdpedia
page (in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3, Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize PDpedia Parties:
It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5 per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta atmosphere
I have also suggested that all PD teachers should give time in their workshops for the students to document on PDpedia the object they are discovering.
Of course, PDpedia is a long term project. There are also many initiatives like the great FLOSSmanuals, or videopedia to produce tutorials.
Because of the 2500 objects/elements, the PDpedia is more on the encyclopedic aspect. 2500 objects and more could be completed in many languages in five years, if the community understand how politically important is to help newbies to use such tools with documentation facilities. Documenting is not sometimes very sexy, that's why I suggest to organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not do it at this time), for an antispam system with a captcha or similar stuff.
JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see
that this
problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing
out well? I
believe "someone" could also direct how things are going, and
that a main
team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful.
Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't think that pdpedia is a replacement or substitute for
interactive help patches. But mediawiki is a great tool for getting
lots of bits of information from a lot of people. So I think that
pdpedia could be used as a place to orgnanize content, like reference
info, links to related algorithms, links to related video tutorials,
etc. That material could then be filtering into the help patches
themselves.
A pd-help file wiki would be great, but until then, I think pdpedia
could be useful.
.hc
On Apr 8, 2009, at 10:35 PM, dmotd wrote:
hi folks,
i am somewhat interested in investing some time in pdpedia, but i have a few concerns with mediawiki as a container for pd related data.
obviously mediawiki is an excellent versioning platform and has a strong following for many technical wiki's in the open-source community. i think its an excellent format for plain text information, which takes the form of tutorials/howto/guide, but as an object reference it has a limited scope.
this is especially the case when attempting to pull that information into another format (ie.. not html). anything pulled off the server using the api needs to be parsed to be made useful in another context, and in many cases reparsed to pick out the meta-references, and this is without getting to the content which is often categorised in an entirely different format.
i have previously invested a fair chunk of time in refencing objects in a sql database, while my work was not designed with versioning in mind, it was designed to be utilised by pd (dd was the projected environment) or pd libs internally, or in other formats like a postscript reference or generating pddp formatted helpfiles. i have recently started picking up the pieces of this project (which i had ceased with the initial announcement of pdpedia).
anyhow, what i am beginning to see a need for is an infrastructure like mediawiki which stores pd files rather than plain-text. think of it like a categorised + tagged svn. this would be a place where people can upload files relating to pd use, examples of usage, methods of interfacing and anything else that gets passed around on this mailing list. keeping with the same wiki format of edits by anyone, and versioning each subsequent edit. then in a similar method to mediawiki api calls, pd internally could request a list of articles (pd-patches) and dynamically retrieve requested articles from the pdwiki. thus making the system much more usable within the pd environment.
i think the benefit of this would be quite obvious to pd-users, as it has been stated many times by numerous people that a plain text wiki reference doesn't really make much sense without the interactive characteristics of an actual patch.
this is something i would happily put energies into development, and in many ways have already started. i will likely end up building something that works in this way anyway, so please throw in suggestions, before i get carried away ;)
ciao,
dmotd
On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote:
There are lots of good ideas worth trying. We've talked about it a lot, we just need someone to take charge of it. I am just too overloaded to handle pdpedia on top of everything else. Who wants to own it?
.hc
On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some french PDers the following features:
- a lexicon-dictionary about objects/externals/abstractions (
Done)
- a category search portal ( one of the most important feature
for pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search: PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add / pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend ( fiction...)
- multilingual structure as Wikipedia ( very important for
educational uses in the world where people will stay with commercial software just for this reason ( France for example)) (Done)
future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches ( parsing of the
patch code to create an image of the patch, server side) and downloading text patches from PDpedia
- Pdpedia database embedded with PD extended ( when completed)
for offline consulting
- in PD: a contextual help with access to the related pdpedia
page (in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3, Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize PDpedia Parties:
It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5 per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta atmosphere
I have also suggested that all PD teachers should give time in their workshops for the students to document on PDpedia the object they are discovering.
Of course, PDpedia is a long term project. There are also many initiatives like the great FLOSSmanuals, or videopedia to produce tutorials.
Because of the 2500 objects/elements, the PDpedia is more on the encyclopedic aspect. 2500 objects and more could be completed in many languages in five years, if the community understand how politically important is to help newbies to use such tools with documentation facilities. Documenting is not sometimes very sexy, that's why I suggest to organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not do it at this time), for an antispam system with a captcha or similar stuff.
JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see
that this
problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing
out well? I
believe "someone" could also direct how things are going, and
that a main
team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful.
Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
yes, i agree that pdpedia/mediawiki has its place, however it is another resource for documentation that is currently competing with the plone wiki reference at puredata.org. This means that we have two distinct references, both apparently supported by the 'pd community', and frankly this just creates another point of confusion and an area where information can quickly become derelict. really we should be attempting to eliminate redundancy where possible.
i am not at all convinced that pdpedia/mediawiki serves as a good method for object reference. it is difficult to maintain (a lot of manual copy and paste), its search/sort functionality is limited, the up/down stream api is severely lacking and most of all it is difficult to integrate it into a pd environment (outside of simple pddp links which are usually inside the object reference anyhow).
so yes, pdpedia is convenient at this stage, but i am more interested in building an environment that will engage better with pd itself, and this is basically what i am proposing.
cheers, dmotd
On Thursday 09 April 2009 12:59:09 Hans-Christoph Steiner wrote:
I don't think that pdpedia is a replacement or substitute for interactive help patches. But mediawiki is a great tool for getting lots of bits of information from a lot of people. So I think that pdpedia could be used as a place to orgnanize content, like reference info, links to related algorithms, links to related video tutorials, etc. That material could then be filtering into the help patches themselves.
A pd-help file wiki would be great, but until then, I think pdpedia could be useful.
.hc
On Apr 8, 2009, at 10:35 PM, dmotd wrote:
hi folks,
i am somewhat interested in investing some time in pdpedia, but i have a few concerns with mediawiki as a container for pd related data.
obviously mediawiki is an excellent versioning platform and has a strong following for many technical wiki's in the open-source community. i think its an excellent format for plain text information, which takes the form of tutorials/howto/guide, but as an object reference it has a limited scope.
this is especially the case when attempting to pull that information into another format (ie.. not html). anything pulled off the server using the api needs to be parsed to be made useful in another context, and in many cases reparsed to pick out the meta-references, and this is without getting to the content which is often categorised in an entirely different format.
i have previously invested a fair chunk of time in refencing objects in a sql database, while my work was not designed with versioning in mind, it was designed to be utilised by pd (dd was the projected environment) or pd libs internally, or in other formats like a postscript reference or generating pddp formatted helpfiles. i have recently started picking up the pieces of this project (which i had ceased with the initial announcement of pdpedia).
anyhow, what i am beginning to see a need for is an infrastructure like mediawiki which stores pd files rather than plain-text. think of it like a categorised + tagged svn. this would be a place where people can upload files relating to pd use, examples of usage, methods of interfacing and anything else that gets passed around on this mailing list. keeping with the same wiki format of edits by anyone, and versioning each subsequent edit. then in a similar method to mediawiki api calls, pd internally could request a list of articles (pd-patches) and dynamically retrieve requested articles from the pdwiki. thus making the system much more usable within the pd environment.
i think the benefit of this would be quite obvious to pd-users, as it has been stated many times by numerous people that a plain text wiki reference doesn't really make much sense without the interactive characteristics of an actual patch.
this is something i would happily put energies into development, and in many ways have already started. i will likely end up building something that works in this way anyway, so please throw in suggestions, before i get carried away ;)
ciao,
dmotd
On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote:
There are lots of good ideas worth trying. We've talked about it a lot, we just need someone to take charge of it. I am just too overloaded to handle pdpedia on top of everything else. Who wants to own it?
.hc
On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some french PDers the following features:
- a lexicon-dictionary about objects/externals/abstractions (
Done)
- a category search portal ( one of the most important
feature for pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search: PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add / pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend ( fiction...)
- multilingual structure as Wikipedia ( very important for
educational uses in the world where people will stay with commercial software just for this reason ( France for example)) (Done)
future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches ( parsing of the
patch code to create an image of the patch, server side) and downloading text patches from PDpedia
- Pdpedia database embedded with PD extended ( when
completed) for offline consulting
- in PD: a contextual help with access to the related pdpedia
page (in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3, Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize PDpedia Parties:
It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5 per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta atmosphere
I have also suggested that all PD teachers should give time in their workshops for the students to document on PDpedia the object they are discovering.
Of course, PDpedia is a long term project. There are also many initiatives like the great FLOSSmanuals, or videopedia to produce tutorials.
Because of the 2500 objects/elements, the PDpedia is more on the encyclopedic aspect. 2500 objects and more could be completed in many languages in five years, if the community understand how politically important is to help newbies to use such tools with documentation facilities. Documenting is not sometimes very sexy, that's why I suggest to organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not do it at this time), for an antispam system with a captcha or similar stuff.
JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see
that this
problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing
out well? I
believe "someone" could also direct how things are going, and
that a main
team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful.
Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, dmotd hat gesagt: // dmotd wrote:
i am not at all convinced that pdpedia/mediawiki serves as a good method for object reference. it is difficult to maintain (a lot of manual copy and paste), its search/sort functionality is limited, the up/down stream api is severely lacking and most of all it is difficult to integrate it into a pd environment (outside of simple pddp links which are usually inside the object reference anyhow).
I believe, reference documentation belongs into the code and additional display methods should be generated from that. What's currently useful in pdpedia mostly was generated by a script, but a year or so ago and it may already be outdated or referring to objects not available anymore (i.e. http://wiki.puredata.info/en/mapping/degrees0x2d0x3emapping)
Ciao
Frank
2009/4/9 Frank Barknecht fbar@footils.org:
Hallo, dmotd hat gesagt: // dmotd wrote:
i am not at all convinced that pdpedia/mediawiki serves as a good method for object reference. it is difficult to maintain (a lot of manual copy and paste), its search/sort functionality is limited, the up/down stream api is severely lacking and most of all it is difficult to integrate it into a pd environment (outside of simple pddp links which are usually inside the object reference anyhow).
I believe, reference documentation belongs into the code and additional display methods should be generated from that.
hi frank, please be more elaborate. are you distinguishing between reference and documentation? is "reference documentation" the help patches or some other kind of object reference. are you talking about code comments? in help patches? or in the C code?
I think that the purpose of documentation is to teach/explain how to use objects? reference might be something slightly different.
the problem imho is that there is no basis right now on which an automatic documentation generation could build on. I also think that autogeneration would be extremely helpful, but... who of the vanilla/external-developers will reliably stick to any rules? since developers are bad documentators but you still propose that code should be the source to generate documentation, how do you think people (who would like to do some documentation) should contribute? directly to the source code?
how do you envision that users will search for objects? where do you think information like tags, similar objects, example patches should come from?
marius.
On Thursday 09 April 2009 23:55:11 marius schebella wrote:
2009/4/9 Frank Barknecht fbar@footils.org:
Hallo,
dmotd hat gesagt: // dmotd wrote:
i am not at all convinced that pdpedia/mediawiki serves as a good method for object reference. it is difficult to maintain (a lot of manual copy and paste), its search/sort functionality is limited, the up/down stream api is severely lacking and most of all it is difficult to integrate it into a pd environment (outside of simple pddp links which are usually inside the object reference anyhow).
I believe, reference documentation belongs into the code and additional display methods should be generated from that.
hi frank, please be more elaborate. are you distinguishing between reference and documentation? is "reference documentation" the help patches or some other kind of object reference. are you talking about code comments? in help patches? or in the C code?
I think that the purpose of documentation is to teach/explain how to use objects? reference might be something slightly different.
the problem imho is that there is no basis right now on which an automatic documentation generation could build on. I also think that autogeneration would be extremely helpful, but... who of the vanilla/external-developers will reliably stick to any rules? since developers are bad documentators but you still propose that code should be the source to generate documentation, how do you think people (who would like to do some documentation) should contribute? directly to the source code?
how do you envision that users will search for objects? where do you think information like tags, similar objects, example patches should come from?
marius.
i'd love to see as much documentation, tags, categories, etc coming directly from the c code itself, heck.. why not even build a pd class library that stores all of this extraneous info internally! but really with the current codebase it is not feasible to make old objects adhere to some new documentation api subset, and unlikely that new object writers would adhere to that anyhow. that's why its important to make documenting pd as simple as possible and as straight forward as contributing to any wiki for text.
frank! your list-abs dynamic reference system is awesome.. that sort of thing should be encouraged everywhere, great job!
dmotd
On Thursday 09 April 2009 23:14:28 Frank Barknecht wrote:
Hallo,
dmotd hat gesagt: // dmotd wrote:
i am not at all convinced that pdpedia/mediawiki serves as a good method for object reference. it is difficult to maintain (a lot of manual copy and paste), its search/sort functionality is limited, the up/down stream api is severely lacking and most of all it is difficult to integrate it into a pd environment (outside of simple pddp links which are usually inside the object reference anyhow).
I believe, reference documentation belongs into the code and additional display methods should be generated from that. What's currently useful in pdpedia mostly was generated by a script, but a year or so ago and it may already be outdated or referring to objects not available anymore (i.e. http://wiki.puredata.info/en/mapping/degrees0x2d0x3emapping)
Ciao
hey frank,
yes this is exactly my point, though pd is not the first language to find methods referenced in documentation are severely outdated. and pd is not a text-based language, so text based documentation is already a hurdle. what i am interested in developing is a wiki that incorporates the pd patcher paradigm, so that reference material and examples can be submitted as pd-code. how this is dismantled and presented in text w/ diagrams is irrelevant as long as the folks looking at a text based reference understand that a greater depth to the same reference exists within pd.
hopefully something a little more personalised to the pd project can come from these qualms/observations :)
cheers,
dmotdf
2009/4/9 dmotd dmotd@gmx.net
what i am interested in developing is a wiki that incorporates the pd patcher paradigm, so that reference material and examples can be submitted as pd-code.
This is so far the best solution.
But why wiki? I think it should be done in a customized CMS, something made with some python parsers and a MVC web framework like Django... (Ruby fans will say Ruby on Rails, but you got the idea)...
This could be a good reason to think about a "Puredata_abstraction to JSON"parser, that was discussed in other thread (DIY GSoC)... Since JSON can be parsed even to a RSS format easily... See that? Read new patches docs at the RSS news?
Than also the string issues could be solved editing .pd documentation in text based editors. And even some web based WSIWYG editor that would generate "pd readable" documentation.... :) Could be?
té+
glerm
sorry, i meant wiki as a shorthand for software revision control, so that there is a trace history of edits and the database can be exported at a given revision.
interesting ideas however, i admit i'm not completely familiar with the JSON format, but i do understand the basis behind this request. definitely something to think about.
dmotd
On Friday 10 April 2009 05:56:54 glerm soares wrote:
2009/4/9 dmotd dmotd@gmx.net
what i am interested in developing is a wiki that incorporates the pd patcher paradigm, so that reference material and examples can be submitted as pd-code.
This is so far the best solution.
But why wiki? I think it should be done in a customized CMS, something made with some python parsers and a MVC web framework like Django... (Ruby fans will say Ruby on Rails, but you got the idea)...
This could be a good reason to think about a "Puredata_abstraction to JSON"parser, that was discussed in other thread (DIY GSoC)... Since JSON can be parsed even to a RSS format easily... See that? Read new patches docs at the RSS news?
Than also the string issues could be solved editing .pd documentation in text based editors. And even some web based WSIWYG editor that would generate "pd readable" documentation.... :) Could be?
té+
glerm
hi dmotd,
your post is great, it reminded me of all the ideas I had before starting pdpedia. my main motivation for working on a pd(pedia) object database/documentation was to help users (including myself) find the right object for their purpose and help developers by preventing redundancy in writing new objects. -- I also got stuck by the limitations of mediawiki. some of the things, for example that I'd like to see: make heavy use of *data mining* in existing pd patches: It should be possible to know, how often an object is used, and how often it is connected to which other object and which objects share the same window. it should even be possible to tell the search engine where in the patch (x/z area) an object was placed. I want to search for objects related to key words, tags, maybe categories (although a fixed structure is definitely a bad idea), libraries, similar objects, sort by all kinds of means (date, popularity, operating system). On top of this pd-base there should be a place like *youtube*, where you can post your own patches, have favorites, have a list of favorite objects. I know that it is not possible (yet) to play a pd patch within a browser, but I am sure someone will come up with a firefox plugin anytime soon. I also think that people should be able to comment on objects, or rate them, or have rss feeds if someone posts a new patch that contains a certain object or is related to a certain topic. and your point about exchanging data formats is extremely important, too. I know that mediawiki has a method to import/export - in theory, but this can by no means compared to a real query api.
of course, maintaining all that information is a hell of a work. that was the point where the wiki idea came into place (a lot of people contributing). but after a year of pdpedia I still don't see this taking off, which makes me want to try out something new. btw is there any literature or real world examples of how other groups/open source communities deal with the *lack of physical/financial resources*?
marius.
2009/4/9 dmotd dmotd@gmx.net:
hi folks,
i am somewhat interested in investing some time in pdpedia, but i have a few concerns with mediawiki as a container for pd related data.
obviously mediawiki is an excellent versioning platform and has a strong following for many technical wiki's in the open-source community. i think its an excellent format for plain text information, which takes the form of tutorials/howto/guide, but as an object reference it has a limited scope.
this is especially the case when attempting to pull that information into another format (ie.. not html). anything pulled off the server using the api needs to be parsed to be made useful in another context, and in many cases reparsed to pick out the meta-references, and this is without getting to the content which is often categorised in an entirely different format.
i have previously invested a fair chunk of time in refencing objects in a sql database, while my work was not designed with versioning in mind, it was designed to be utilised by pd (dd was the projected environment) or pd libs internally, or in other formats like a postscript reference or generating pddp formatted helpfiles. i have recently started picking up the pieces of this project (which i had ceased with the initial announcement of pdpedia).
anyhow, what i am beginning to see a need for is an infrastructure like mediawiki which stores pd files rather than plain-text. think of it like a categorised + tagged svn. this would be a place where people can upload files relating to pd use, examples of usage, methods of interfacing and anything else that gets passed around on this mailing list. keeping with the same wiki format of edits by anyone, and versioning each subsequent edit. then in a similar method to mediawiki api calls, pd internally could request a list of articles (pd-patches) and dynamically retrieve requested articles from the pdwiki. thus making the system much more usable within the pd environment.
i think the benefit of this would be quite obvious to pd-users, as it has been stated many times by numerous people that a plain text wiki reference doesn't really make much sense without the interactive characteristics of an actual patch.
this is something i would happily put energies into development, and in many ways have already started. i will likely end up building something that works in this way anyway, so please throw in suggestions, before i get carried away ;)
ciao,
dmotd
On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote:
There are lots of good ideas worth trying. We've talked about it a lot, we just need someone to take charge of it. I am just too overloaded to handle pdpedia on top of everything else. Who wants to own it?
.hc
On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some french PDers the following features:
- a lexicon-dictionary about objects/externals/abstractions (
Done)
- a category search portal ( one of the most important feature
for pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search: PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add / pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend ( fiction...)
- multilingual structure as Wikipedia ( very important for
educational uses in the world where people will stay with commercial software just for this reason ( France for example)) (Done)
future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches ( parsing of the
patch code to create an image of the patch, server side) and downloading text patches from PDpedia
- Pdpedia database embedded with PD extended ( when completed)
for offline consulting
- in PD: a contextual help with access to the related pdpedia
page (in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3, Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize PDpedia Parties:
It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5 per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta atmosphere
I have also suggested that all PD teachers should give time in their workshops for the students to document on PDpedia the object they are discovering.
Of course, PDpedia is a long term project. There are also many initiatives like the great FLOSSmanuals, or videopedia to produce tutorials.
Because of the 2500 objects/elements, the PDpedia is more on the encyclopedic aspect. 2500 objects and more could be completed in many languages in five years, if the community understand how politically important is to help newbies to use such tools with documentation facilities. Documenting is not sometimes very sexy, that's why I suggest to organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not do it at this time), for an antispam system with a captcha or similar stuff.
JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see
that this
problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing
out well? I
believe "someone" could also direct how things are going, and
that a main
team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful.
Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey marius,
okay, well i think we're on the same page here, what you describe and what's in my head seem to be somewhat aligned. i have a little bit of time spare at present and a fair bit of experience developing web based content management systems, so hopefully these ideas could gather a little momentum.
what is important here is that there is a layer that is consistent between all interfaces connecting to it (ie. the database), and the way that this inforation is organised and presented can vary depending on the interface.
it is also very important to make sure that the reference is maintainable, and where possible self documenting. this is where your data mining experiments are valuable, any statistics that we can easily gather, help to build the picture of how pd operates, and could certainly aid in the development of pd into the future. i know there is a limit to what can be automated and often automated content is more of a pain than a help, but a few small things may help with maintenance issues.
for example plugging into the output of CIA (which pd is a subscriber to), should allow the object database to easily monitor changes to the svn, which in turn could create a section of 'watched' objects that would provide a list of known changes to objects (however small) and warn potential contributors that the object internals have changed and the reference may need to be updated.
when i initially started building my own database, i wanted to have a little picture of the object being described, with all of its inlets and outlets present. i decided to draw this using GD (a php graphing app), but in order to do so i had to document the inlets and outlets that were present, and those that were created dynamically on init - which meant documenting the init arguments too. this small exercise in futility helped expand the reference to include a bit more detail on each class, which i now recognise is invaluable to the database (and myself) having a stronger knowledge of pd internals. and now i have something that could potentially draw *basic* pd patch code without having to use pd as a server, or analyse pd patches with finer precision.
another example, i used your CSV file to build a small sh script that can analyse a pd patch and an abstraction folder, and list missing objects (and unique objects for that matter) required for that patch. with a bit more work this could very easily direct users to the libraries they're missing. (i realise that loading the patch into pd spits out this sort of information anyway, but there are times where i would like to check this first - and yes running pd-extended probably sorts out everything anyway, but that isn't always possible).
while the current list of objects and abstractions is quite intimidating, getting at least the object list completed and finding methods to extract the rest may be quite easily achieved. i think as you say making this database as approachable as possible to users, so that they can upload, comment, rank and favourite patches/abstractions/objects, will make pd generally a more inclusive environment and something that becomes a solution to more peoples problems. in a sense the more people that are contributing to higher level projects, the more interest there is in documenting the lowerlevel objects. i think this is in a sense where hcs is at with pd-extended, but what is missing with pdpedia/plone.
for me the plone space is buried in the logic of private spaces - places to hold your projects (home folders), but not really to mass distribution in a true wiki sense, or as you describe it a 'youtube' space (which is indeed a better metaphor for the distribution of patches/objects/libs etc)
so yeah.. this seems to be a shared interest and something potentially to build upon.. on a side note, i took up this project a few years ago when pddb finally breathed its last breath, which for me was the best resource for searching the object library outside of hassling the pd-list. i still don't think pdpedia has filled those shoes, which were in fact very simple and tidy, but i digress..
thanks for your encouraging response!
dmotd
On Thursday 09 April 2009 18:24:13 marius schebella wrote:
hi dmotd,
your post is great, it reminded me of all the ideas I had before starting pdpedia. my main motivation for working on a pd(pedia) object database/documentation was to help users (including myself) find the right object for their purpose and help developers by preventing redundancy in writing new objects. -- I also got stuck by the limitations of mediawiki. some of the things, for example that I'd like to see: make heavy use of *data mining* in existing pd patches: It should be possible to know, how often an object is used, and how often it is connected to which other object and which objects share the same window. it should even be possible to tell the search engine where in the patch (x/z area) an object was placed. I want to search for objects related to key words, tags, maybe categories (although a fixed structure is definitely a bad idea), libraries, similar objects, sort by all kinds of means (date, popularity, operating system). On top of this pd-base there should be a place like *youtube*, where you can post your own patches, have favorites, have a list of favorite objects. I know that it is not possible (yet) to play a pd patch within a browser, but I am sure someone will come up with a firefox plugin anytime soon. I also think that people should be able to comment on objects, or rate them, or have rss feeds if someone posts a new patch that contains a certain object or is related to a certain topic. and your point about exchanging data formats is extremely important, too. I know that mediawiki has a method to import/export - in theory, but this can by no means compared to a real query api.
of course, maintaining all that information is a hell of a work. that was the point where the wiki idea came into place (a lot of people contributing). but after a year of pdpedia I still don't see this taking off, which makes me want to try out something new. btw is there any literature or real world examples of how other groups/open source communities deal with the *lack of physical/financial resources*?
marius.
2009/4/9 dmotd dmotd@gmx.net:
hi folks,
i am somewhat interested in investing some time in pdpedia, but i have a few concerns with mediawiki as a container for pd related data.
obviously mediawiki is an excellent versioning platform and has a strong following for many technical wiki's in the open-source community. i think its an excellent format for plain text information, which takes the form of tutorials/howto/guide, but as an object reference it has a limited scope.
this is especially the case when attempting to pull that information into another format (ie.. not html). anything pulled off the server using the api needs to be parsed to be made useful in another context, and in many cases reparsed to pick out the meta-references, and this is without getting to the content which is often categorised in an entirely different format.
i have previously invested a fair chunk of time in refencing objects in a sql database, while my work was not designed with versioning in mind, it was designed to be utilised by pd (dd was the projected environment) or pd libs internally, or in other formats like a postscript reference or generating pddp formatted helpfiles. i have recently started picking up the pieces of this project (which i had ceased with the initial announcement of pdpedia).
anyhow, what i am beginning to see a need for is an infrastructure like mediawiki which stores pd files rather than plain-text. think of it like a categorised + tagged svn. this would be a place where people can upload files relating to pd use, examples of usage, methods of interfacing and anything else that gets passed around on this mailing list. keeping with the same wiki format of edits by anyone, and versioning each subsequent edit. then in a similar method to mediawiki api calls, pd internally could request a list of articles (pd-patches) and dynamically retrieve requested articles from the pdwiki. thus making the system much more usable within the pd environment.
i think the benefit of this would be quite obvious to pd-users, as it has been stated many times by numerous people that a plain text wiki reference doesn't really make much sense without the interactive characteristics of an actual patch.
this is something i would happily put energies into development, and in many ways have already started. i will likely end up building something that works in this way anyway, so please throw in suggestions, before i get carried away ;)
ciao,
dmotd
On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote:
There are lots of good ideas worth trying. We've talked about it a lot, we just need someone to take charge of it. I am just too overloaded to handle pdpedia on top of everything else. Who wants to own it?
.hc
On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
It would be good to have standards on how articles should be formatted and what kind of information should be presented.
yes I agree. At the origin in 2006..., I have suggested to some french PDers the following features:
- a lexicon-dictionary about objects/externals/abstractions
( Done)
- a category search portal ( one of the most important
feature for pd newbies ), like in Wikipedia portal http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cat%C3%A9gories ( to do)
Example of category search: PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add / pix_subtract /pix_diff /pix_composite/ pix_multiply/ PDP_blend ( fiction...)
- multilingual structure as Wikipedia ( very important for
educational uses in the world where people will stay with commercial software just for this reason ( France for example)) (Done)
future options, when the database will be completed enough:
- tools or wiki tags for visualizing patches ( parsing of
the patch code to create an image of the patch, server side) and downloading text patches from PDpedia
- Pdpedia database embedded with PD extended ( when
completed) for offline consulting
- in PD: a contextual help with access to the related
pdpedia page (in PD itself or online)
About the formatting of one page, I have suggested the rubriques:
(from the body of the page)
Nature of the element (object/external/abstraction/ Short Definition Generalities (long definition) Compatibility ( wich versions of pd)
Inlets Outlets Arguments Messages
Warnings and incompatibilities Tricks and alternative ways to do it Examples ( expanded help file+ other examples with pictures), links to video examples Tutorials on this element, links to videos Associated objects, related objects Equivalents in similar open source softwares
Author(s) of the object, links Contributors of this page.
(from the infobox) name ultra short description abbreviation library author developer release version release date dependencies license website programming language platform (i.e Windows, Mac OS X, GNU/Linux) operating system (i.e. Windows XP, Windows 2000, Mac OS X 10.3, Debian, etc.) language data type distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc) link to the code
about the work to do on the PDpedia, I have suggested to organize PDpedia Parties:
It's a on day or two days fiesta gathering, where PDers decide: -first : how many objects they will document, and wich objects ( 5 per person during 3 hours for example) -then they document individually, in a fiesta atmosphère, during a limited amount of time. -then, they create collective(s) performance(s) in a complete fiesta atmosphere
I have also suggested that all PD teachers should give time in their workshops for the students to document on PDpedia the object they are discovering.
Of course, PDpedia is a long term project. There are also many initiatives like the great FLOSSmanuals, or videopedia to produce tutorials.
Because of the 2500 objects/elements, the PDpedia is more on the encyclopedic aspect. 2500 objects and more could be completed in many languages in five years, if the community understand how politically important is to help newbies to use such tools with documentation facilities. Documenting is not sometimes very sexy, that's why I suggest to organise PDpedia parties.
and yes, I agree, there is a need for some maintainers ( I can not do it at this time), for an antispam system with a captcha or similar stuff.
JN
2009/3/31 Alexandre Porres <porresgmail.com>:
so we need :someone" to manage the system, ok, but then I see
that this
problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing
out well? I
believe "someone" could also direct how things are going, and
that a main
team could work on it by fomenting its development and all... right?
Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful.
Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
dmotd -
Frank Barknecht -
glerm soares -
Hans-Christoph Steiner -
Jean-Noël Montagné -
marius schebella