[PD] beat detection

Jamie Bullock jamie at postlude.co.uk
Fri Apr 10 10:47:34 CEST 2009


The aubio library needs to be loaded at startup. Preferences ->  
Startup... then add 'aubio' (without the quotes) to the list.

Then relaunch Pd. You should get a reassuring: 'aubio external for pd,  
version 0.1' posted to the console and be able to load [aubioonset~]

If not, let me know any error messages you get.

best,

Jamie


--
http://www.jamiebullock.com



On 9 Apr 2009, at 16:41, Alexandre Porres wrote:

> 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
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list