On Sat, Feb 25, 2012 at 8:59 PM, Mathieu Bouchard <[email protected]> wrote:
>> A collection of useful routines which may be used individually, or >> combined as integrated analysis-engine, in the context of a framework like >> Pd, MaxMsp, SuperCollider. > > > Can you be more specific about what this will be ? It's about the extraction of time domain features from an audio signal, mainly period length and note detection. Procedures to find these parameters will have best results if they can connect to each other at some points, and that is the reason to make an integrated lib. For efficiency, a multirate approach with polyphase FIR filtering will be applied. I've posted an outline to Pd forum (post #1 and #13): http://puredata.hurleur.com/sujet-6814-rap-realtime-analysis-project And the period detector code is now in a Pd class [helmholtz~]: http://www.katjaas.nl/helmholtz/helmholtz.html >> I use to link GNU C++ standard libs statically, just in case my class >> is used with a Pd which doesn't have them. This adds more than 100 KB >> to the executable size, not so nice detail. > > > Isn't this mostly when you use STL ? The use of STL is optional. For > example, I almost never use #include <fstream> in C++, I still prefer > <stdio.h>. I do not use STL functionality, libstdc++ seems to be required for other functions as well, and vanilla Pd can't load a C++ object without it. >> A C lib would not impose all these concerns on an application programmer. >> I'm inclined to look at C once more. > > > Instead, a C lib will impose other concerns that C++ won't. What will those > be ? Actually, I can't think of any at the moment. That's partly by lack of experience. I'm planning to provide an unambiguous interface with 'new', 'free' and access methods. But most of it must still be designed. Katja _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
