On Sun, Feb 26, 2012 at 11:49 AM, Jamie Bullock jamie.b.bullock@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