On Sat, Feb 25, 2012 at 8:59 PM, Mathieu Bouchard matju@artengine.ca 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