On Wed, Jul 15, 2015 at 2:21 PM, James Bullock <[email protected]> wrote:
> On 15 July 2015 at 11:57:17, katja ([email protected]) 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
