Re: [PD] Pdpedia and random generation

2009-04-10 Thread Luke Iannini
On Tue, Mar 31, 2009 at 2:09 PM, Philip Potter
philip.g.pot...@gmail.com wrote:
 2009/3/31 Alexandre Porres por...@gmail.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.
Yo -
I made this
http://wiki.puredata.info/en/switch%7E
long ago with the intention of it serving as an example (but of
course, it could use improvement).

As you can see, it makes use of a few tricks for styling object
references I added when Pdpedia was birthed - I think they were
forgotten though : ).  Check out the source to see how they're done.

Best
Luke



 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?

 Philip

 ___
 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


Re: [PD] Pdpedia and random generation

2009-04-09 Thread marius schebella
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 dm...@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 

Re: [PD] Pdpedia and random generation

2009-04-09 Thread dmotd
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 

Re: [PD] Pdpedia and random generation

2009-04-09 Thread Frank Barknecht
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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-04-09 Thread marius schebella
2009/4/9 Frank Barknecht f...@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.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-04-09 Thread dmotd
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 

Re: [PD] Pdpedia and random generation

2009-04-09 Thread dmotd
On Thursday 09 April 2009 23:55:11 marius schebella wrote:
 2009/4/9 Frank Barknecht f...@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




 

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-04-09 Thread 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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-04-09 Thread Alexandre Porres
well, to host a convention here is definately and effort to put
S.America in the game.

What you are discussing feels to me like one of the best issues to
raise up in Round Tables.

Actually, Round tables were said to be proposed here on the list, so
lets talk about this more later on.

I am up for parties alright...

2009/4/9 Jean-Noël Montagné j...@rom.fr:

 Salut Hans and PD community

 First of all, thank you very much for all work you have done for the idea
 and server services. I am very busy for working for living, but also for
 Bricolabs.net projects ( bricophone.org, fluxtation.org, oswash.org), and I
 still can't handle the pdpedia project yet.

 I think there could be newcomers to PD ready to assume this kind of
 responsability, individually or collectivelly. Did I have understood that
 Alexandre Porres and other PD users from Brazil could help us to find some
 people in south america ?
 it would be good to displace more the center of gravity of PD users in
 direction of the south ! and for many reasons Brazil will be the next PD
 country/community...
 Some people also have some grants to work on open source, wich is impossible
 in France for example...
 The profile needed is someone able to do some Wikipedia maintaining and
 hacking.

 Cheers,
 JN

 PS: what about a giant multilingual PDpedia party, PDFlossManual Party,
 PDVideopediaParty in the next PDconvention ?


 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




-- 
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-04-09 Thread dmotd
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 dm...@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 JSONparser, 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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-04-08 Thread Hans-Christoph Steiner


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~

Re: [PD] Pdpedia and random generation

2009-04-08 Thread dmotd
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
  

Re: [PD] Pdpedia and random generation

2009-04-08 Thread Hans-Christoph Steiner


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

Re: [PD] Pdpedia and random generation

2009-04-01 Thread Jean-Noël Montagné






 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

Re: [PD] Pdpedia and random generation

2009-04-01 Thread IOhannes m zmoelnig

Alexandre Porres wrote:

Do we want pdpedia to just be a reference manual of objects?

I think it is a good start. To have a list of Every Object out there, and
make clear which are written, and the ones who are not.


does this mean that you want to make a reference manual of Every Object, 
 no matter whether it has been implemented or not?




A nice and simple model must be followed, we could think about expanding
pdpedia for other info later, as I believe this is very urgent.


but what keeps us from doing this right now? what has kept us from doing 
so in the past few years of pdpedia's existance?

what shall we do to avoid becoming a honeypot?

asdmr
IOhannes




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-31 Thread Philip Potter
2009/3/31 Georg Holzmann g...@mur.at:
 Hallo!

 afaik, pdpedia is poorly maintained at the moment. I think there will be
 a better solution in the future to get rid of spam and optimize searching
 and contributions. for now, your observation of burnout seems correct.
 marius.

 I think pdpedia has a lot of potential, but it needs someone to take
 ownership of it.  Its really open to anyone who wants to take it on.  It is
 useful now for searching based on keywords.  I use it to find objects based
 on key words.

I quite agree, and I have written for some articles to make them more
useful (FIR~, multiplex~, and tabwrite) but I feel lonely doing so.
I'm the only user to have made any changes to pdpedia content in the
last 30 days; there has been some spamfighting by Hans and lots of
spam from anonymous IPs but if noone else is updating the actual
content I don't see why I am doing it.

 Silly question: but why don't you just use captchas did get rid of all these
 massive spam attacks ?
 (However, I don't know if this is difficult to install on this system -
 otherwise maybe have to use user accounts ...)

http://www.mediawiki.org/wiki/Extension:SpamBlacklist is something
that could be considered. It prevents any edit to a page which inserts
a URL matching a list of regexes.

Philip

-- 
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
  --Bjarne Stroustrup

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-31 Thread Alexandre Porres
Hi, welll, so someone needs to take over?
I would definately be interested on this. I do, nevertheless, feel I bit
clueless as I dont know the way to the source of all objects. And cant
really be an expert on things other than audio/music.

I also consider rather unfair to be the work of only one ho has taken over.
I do believe in forming a team, things like that.

Anyway, with the convention this year and all, I hope to bring this issue
into round tables and discussions, make some noise on the list to see if a
small group would move a bit their asses to launch this out.

I could kinda take it over this way. I could definately make the commitment.
But I cant be the one and only. I am not even a Native Speaker/Writer of
English.

So please help me out here, I also need a partner to guide me and help me
not getting so bit clueless.

Cheers
Alex
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-31 Thread marius schebella
the someone would be in charge of the server space and the
maintainance of the mediawiki (accounts, updates, spam, search
functionality, synchronization with other documentations). this could
also be done by several people, but usually the responsibility is with
one person. all the rest can easily be done by a group of admins or
even be totally open to the public.

I guess the work that is missing at the moment is not so much about
writing all the articles.
marius.

2009/3/31 Alexandre Porres por...@gmail.com:
 Hi, welll, so someone needs to take over?
 I would definately be interested on this. I do, nevertheless, feel I bit
 clueless as I dont know the way to the source of all objects. And cant
 really be an expert on things other than audio/music.
 I also consider rather unfair to be the work of only one ho has taken over.
 I do believe in forming a team, things like that.
 Anyway, with the convention this year and all, I hope to bring this issue
 into round tables and discussions, make some noise on the list to see if a
 small group would move a bit their asses to launch this out.
 I could kinda take it over this way. I could definately make the commitment.
 But I cant be the one and only. I am not even a Native Speaker/Writer of
 English.
 So please help me out here, I also need a partner to guide me and help me
 not getting so bit clueless.
 Cheers
 Alex

 ___
 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


Re: [PD] Pdpedia and random generation

2009-03-31 Thread olsen wolf
the server space  the maintenance is currently done by claudio the
sys-admin at the school here in zürich where the wiki is hostet atm.
so far he's been trying to maintain it as much as possible - sometimes
certain request take more time - queuing up on other things that need
to be done. but so far ev'rything should be on the line. recently
php-admin was installed for user management  should be up 
functional. the spam issue we've discussed on the list  i got the
consensus to clean up the mess by hand.
So if there's any lack regarding the hosting or enhancements please
let me know  i'll forward it.
olsen



On Tue, Mar 31, 2009 at 2:46 PM, marius schebella
marius.schebe...@gmail.com wrote:
 the someone would be in charge of the server space and the
 maintainance of the mediawiki (accounts, updates, spam, search
 functionality, synchronization with other documentations). this could
 also be done by several people, but usually the responsibility is with
 one person. all the rest can easily be done by a group of admins or
 even be totally open to the public.

 I guess the work that is missing at the moment is not so much about
 writing all the articles.
 marius.

 2009/3/31 Alexandre Porres por...@gmail.com:
 Hi, welll, so someone needs to take over?
 I would definately be interested on this. I do, nevertheless, feel I bit
 clueless as I dont know the way to the source of all objects. And cant
 really be an expert on things other than audio/music.
 I also consider rather unfair to be the work of only one ho has taken over.
 I do believe in forming a team, things like that.
 Anyway, with the convention this year and all, I hope to bring this issue
 into round tables and discussions, make some noise on the list to see if a
 small group would move a bit their asses to launch this out.
 I could kinda take it over this way. I could definately make the commitment.
 But I cant be the one and only. I am not even a Native Speaker/Writer of
 English.
 So please help me out here, I also need a partner to guide me and help me
 not getting so bit clueless.
 Cheers
 Alex

 ___
 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




-- 
Planet Pluto bleibt!

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-31 Thread Philip Potter
2009/3/31 olsen wolf sesselastron...@googlemail.com:
 the server space  the maintenance is currently done by claudio the
 sys-admin at the school here in zürich where the wiki is hostet atm.
 so far he's been trying to maintain it as much as possible - sometimes
 certain request take more time - queuing up on other things that need
 to be done. but so far ev'rything should be on the line. recently
 php-admin was installed for user management  should be up 
 functional. the spam issue we've discussed on the list  i got the
 consensus to clean up the mess by hand.

I don't know what you mean by clean it up by hand but if you just
mean users deleting spam edits then this is not sustainable. The spam
edits are automated and so they will win any editwar. To combat spam,
we need something systematic: block the spam IPs, use MediaWiki Spam
Blacklist, or require users to create an account before they can edit.

The first solution could be implemented by creating more wiki admins
with the power to block IPs. Obviously said people would need to be
active and trusted. The other options require changing the mediawiki
settings which can presumably only be done by the site admin.

 So if there's any lack regarding the hosting or enhancements please
 let me know  i'll forward it.

-- 
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
  --Bjarne Stroustrup

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-31 Thread Georg Holzmann

Hallo!


I don't know what you mean by clean it up by hand but if you just
mean users deleting spam edits then this is not sustainable. The spam
edits are automated and so they will win any editwar. To combat spam,


+1


we need something systematic: block the spam IPs, use MediaWiki Spam
Blacklist, or require users to create an account before they can edit.


Yes, or use at least captchas (if we don't want to force people to make 
an account) ...


LG
Georg

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-31 Thread Philip Potter
2009/3/31 Alexandre Porres por...@gmail.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?

Philip

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-30 Thread marius schebella

Philip Potter wrote:

Hi all,

First post to the list, very new to pd, hello to all. I have a few questions:

1) Is pdpedia a serious project? It seems like there was a lot of
activity some time ago, but the people there got burned out and now is
a target for spammers (particularly the myobject and help patch
pages). I have done some updating of it but if noone else is doing
anything to it then maybe I should be looking for other pd resources.


hi philip,
afaik, pdpedia is poorly maintained at the moment. I think there will be 
a better solution in the future to get rid of spam and optimize 
searching and contributions. for now, your observation of burnout seems 
correct.

marius.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-30 Thread Mathieu Bouchard

On Mon, 30 Mar 2009, Philip Potter wrote:


3) Someone mentioned on the list a [pack 0 0 0 0 0] idiom for building
large trees of maths in order to avoid weaving many [t b f] objects to
cold inlets. How does this idiom work?


It doesn't eliminate the [t b f], it makes them more manageable.

it's just a bunch of [inlets] connected to a [pack 0 0 0 0 0] then to an 
[unpack 0 0 0 0 0]. This causes recomputation of the complete tree of 
maths every time something is sent to the hot inlet of the abstraction, 
but it doesn't fix anything arising from crossing wires in ways that would 
usually cause a delay: for example if you use [t f f] with crossed wires 
to an object, instead of using [swap], this causes a delay (intentional or 
not) due to order of operations.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-30 Thread Hans-Christoph Steiner


On Mar 30, 2009, at 5:46 PM, marius schebella wrote:


Philip Potter wrote:

Hi all,
First post to the list, very new to pd, hello to all. I have a few  
questions:

1) Is pdpedia a serious project? It seems like there was a lot of
activity some time ago, but the people there got burned out and now  
is

a target for spammers (particularly the myobject and help patch
pages). I have done some updating of it but if noone else is doing
anything to it then maybe I should be looking for other pd resources.


hi philip,
afaik, pdpedia is poorly maintained at the moment. I think there  
will be a better solution in the future to get rid of spam and  
optimize searching and contributions. for now, your observation of  
burnout seems correct.

marius.


I think pdpedia has a lot of potential, but it needs someone to take  
ownership of it.  Its really open to anyone who wants to take it on.   
It is useful now for searching based on keywords.  I use it to find  
objects based on key words.


.hc



If you are not part of the solution, you are part of the problem.



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list