[PD] beat detection

Alexandre Porres porres at gmail.com
Thu Apr 9 17:41:22 CEST 2009


aubio is available at Jamie's Postlude Distribution of Pd-Extended for
mac os only

But it is not working here with me...

jamie?

cheers


On Thu, Apr 9, 2009 at 11:31 AM,  <pd-list-request at iem.at> wrote:
> Send Pd-list mailing list submissions to
>        pd-list at 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-request at iem.at
>
> You can reach the person managing the list at
>        pd-list-owner at 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 <santorcuato76 at gmail.com>
> Subject: [PD] new arduino mega
> To: PD List <pd-list at iem.at>
> Message-ID:
>        <4345df630904090658r4bf4f1a4g26c2daa6ec7ee7ad at 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 <dmotd at gmx.net>
> Subject: Re: [PD] Pdpedia and random generation
> To: marius schebella <marius.schebella at gmail.com>
> Cc: pd-list at iem.at
> Message-ID: <200904100007.43420.dmotd at 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 <dmotd at 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 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
>> >
>> > _______________________________________________
>> > Pd-list at 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 <dmotd at gmx.net>
> Subject: Re: [PD] Pdpedia and random generation
> To: pd-list at iem.at
> Cc: marius schebella <marius.schebella at gmail.com>
> Message-ID: <200904100021.44609.dmotd at 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 <fbar at 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 <dmotd at gmx.net>
> Subject: Re: [PD] Pdpedia and random generation
> To: pd-list at iem.at
> Message-ID: <200904100009.04978.dmotd at 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" <tedthetrumpet at gmail.com>
> Subject: Re: [PD] beat detection
> To: "Pd-list at iem.at" <Pd-list at iem.at>
> Message-ID: <C603C3F2.3FD56%tedthetrumpet at 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 at 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
> ***************************************
>



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




More information about the Pd-list mailing list