[PD] C++ for reusable dsp lib - or better use C?

[katja]

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