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

[katja]

On Sun, Feb 26, 2012 at 11:49 AM, Jamie Bullock
<jamie.b.bullock at gmail.com> wrote:

> I follow your work with interest, and this sounds like a promising new development. I think writing generic routines, e.g. in the form of a shared library that can then support bindings for various contexts is a good one since it enables your work work to have benefits beyond Pd. This was the approach I took with libxtract, which you may be interested in from a feature extraction perspective.
>
> Also, have you looked at BBcut for SuperCollider at all? Sounds like you're trying to do a similar thing and it may be worth looking at how Nick Collins has solved some of the problems. I'd love to see a libBBcut or similar. I guess the key challenge is handling timing and scheduling for the real-time "cut n paste" without duplicating functionality already provided by Pd, SC or whatever.



Thanks for your pointers, Jamie. I had not come across your libxtract
project yet. It's very rich in functionality. And Nick Collins yes, he
brings a lot of interesting signal analysis work to the realtime /
open source community, but seems to forget Pd for some reason.

With a lot of useful projects already available (also think of Aubio),
it may seem a bit weird that I feel a need to add yet another new lib.
But it was the better-than-expected quality and efficiency of pitch
tracker [helmholtz~] which made me think that I could contribute
something. It shall be a compact library, not focusing on width but on
depth: quality, robustness and efficiency of a few procedures which I
consider essential for real time cut & paste. Algorithmic
recomposition won't be part of it, that can be done in patches.

My lib will mainly deliver cuepoints and pitch reports. But some
'customers' for this sort of data must live together with the analysis
in one Pd class, where they can share the time index associated with
the analysis process. A PSOLA pitch shifter for example. Or a
signal&cuepoint recorder like [slicerec~]. In the end, analysis and
processing procedures must be integrated in that one lib to get access
to the time index.

This 'central clock' is the key challenge indeed. It's cycle depends
on the largest buffer size associated with the procedures, and for
efficiency it must always be a power of two. Other cycles can be found
by bitmasking the central clock. Well I've handled it in [slicerec~],
it is a matter of upscaling the principle to more complex
interactions.


Katja