[PD] Pdpedia and random generation

dmotd dmotd at gmx.net
Thu Apr 9 11:47:02 CEST 2009


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édia:Catégories ( 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 at 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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list






More information about the Pd-list mailing list