[PD] LibXtract for Pd?

[katja]

On Wed, Jul 15, 2015 at 2:21 PM, James Bullock <James.Bullock at bcu.ac.uk> wrote:

> On 15 July 2015 at 11:57:17, katja (katjavetter at gmail.com) wrote:
...
> For a library so systematic as LibXtract it makes sense to avoid
> wrapper code duplication. But will the extra complexity and overhead
> of Flext be justified in the case of these two wrapper externals plus
> corresponding makefiles?
>
> Do you mean runtime overhead or maintenance overhead? I’ve never set out to measure the runtime overhead of Flext, but my impression is that it’s insignificant and certainly I’ve never noticed it. But if there is evidence suggesting otherwise, I’d be interested to know about it.
>
> In terms of maintenance / build complexity, since commit 73bd8015 Flext is greatly simplified (through the use of C++ templates), requiring only a single header include; no more building and link static libraries! This means to support a flext external only two steps are needed: 1. add the Flext repository as a git submodule, 2. include flext.h

Ow, if Flext complexity is hidden from the user nowadays I eat my
words (which were based on past experience).

> BTW, I’m planning to support a wider range of F0 detection methods, including at some point your own Helmholtz algorithm.

Frankly I was thinking about how to split up routines in helmholtz~
such that it doesn't calculate a spectrum all for itself. That was
exactly the reason I looked at the design of LibXtract. But the point
with helmholtz~ is, I found that it needs to go back from
autocorrelation function to spectrum for refinement calculations in
the case of a high frequency fundamentals. The cascade approach would
not work here, I have to puzzle a bit more.

Katja