Send Pd-list mailing list submissions to
pd-list@iem.at
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.puredata.info/listinfo/pd-list
or, via email, send a message with subject or body 'help' to
pd-list-requ...@iem.at
You can reach the person managing the list at
pd-list-ow...@iem.at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pd-list digest..."
Today's Topics:
1. new arduino mega (Jose Luis Santorcuato)
2. Re: Pdpedia and random generation (dmotd)
3. Re: Pdpedia and random generation (dmotd)
4. Re: Pdpedia and random generation (dmotd)
5. Re: beat detection (J. Simon van der Walt)
----------------------------------------------------------------------
Message: 1
Date: Thu, 9 Apr 2009 09:58:23 -0400
From: Jose Luis Santorcuato <santorcuat...@gmail.com>
Subject: [PD] new arduino mega
To: PD List <pd-list@iem.at>
Message-ID:
<4345df630904090658r4bf4f1a4g26c2daa6ec7ee...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
HI everybody... the new arduino mega is here, but i think the ide
program
and the pduino object must update...Hans.... is possible???? or is
possible
change parameteres in firmata and pduino??? well... just a
questions...
Have a nice day friends
Check the blog... the firts video in in Spanish and the secon English
Thanks a lot
Cheers from Chile
Jos? Luis
--
http://arselectronicachile.blogspot.com/
www.myspace.com/santorcuato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090409/2aa048f9/attachment-0001.htm
>
------------------------------
Message: 2
Date: Fri, 10 Apr 2009 00:07:43 +1000
From: dmotd <dm...@gmx.net>
Subject: Re: [PD] Pdpedia and random generation
To: marius schebella <marius.schebe...@gmail.com>
Cc: pd-list@iem.at
Message-ID: <200904100007.43420.dm...@gmx.net>
Content-Type: text/plain; charset="iso-8859-1"
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 <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 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@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
------------------------------
Message: 3
Date: Fri, 10 Apr 2009 00:21:44 +1000
From: dmotd <dm...@gmx.net>
Subject: Re: [PD] Pdpedia and random generation
To: pd-list@iem.at
Cc: marius schebella <marius.schebe...@gmail.com>
Message-ID: <200904100021.44609.dm...@gmx.net>
Content-Type: text/plain; charset="iso-8859-1"
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
------------------------------
Message: 4
Date: Fri, 10 Apr 2009 00:09:04 +1000
From: dmotd <dm...@gmx.net>
Subject: Re: [PD] Pdpedia and random generation
To: pd-list@iem.at
Message-ID: <200904100009.04978.dm...@gmx.net>
Content-Type: text/plain; charset="iso-8859-1"
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
------------------------------
Message: 5
Date: Thu, 09 Apr 2009 15:25:38 +0100
From: "J. Simon van der Walt" <tedthetrum...@gmail.com>
Subject: Re: [PD] beat detection
To: "Pd-list@iem.at" <Pd-list@iem.at>
Message-ID: <c603c3f2.3fd56%tedthetrum...@gmail.com>
Content-Type: text/plain; charset="US-ASCII"
Oddly enough, having had some success with BBCut in SC, I was
thinking about
asking about beat tracking in Pd also. This looks interesting;
[aubioonset~]
|
[rhythm]
but... so far I've figured out that aubio doesn't seem to be
included in
Pd-extended, that it comes from http://aubio.org/, but beyond that
I'm
finding it hard to track down info on what to do next. Any hints as
to how
to install it? Ideally an intel binary for OS X 10.4, plus a
windows version
as well?
Thanks,
JS
------------------------------
_______________________________________________
Pd-list mailing list
Pd-list@iem.at
to manage your subscription (including un-subscription) see
http://lists.puredata.info/listinfo/pd-list
End of Pd-list Digest, Vol 49, Issue 55
***************************************
