Hi Jamie, would you consider having LibXtract available in the new Deken plugin?
That'd be great :) 2015-07-15 9:21 GMT-03:00 James Bullock <james.bull...@bcu.ac.uk>: > Hi, > > On 15 July 2015 at 11:57:17, katja (katjavet...@gmail.com) wrote: > > Hi Jamie, > > Thanks for your response. I cloned the repo to see the history, and > noticed a tendency of simplification: FFTW replaced by Ooura, > autotools build system replaced by makefiles. Nice! In fact the whole > library looks much simpler than one would expect for the given > functionality. Even the Pd and MaxMSP wrappers were amazingly small > and simple files. > > > Thanks. It’s good to know my attempts to “keep it simple” are > appreciated :) > > 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 > > If the build system is your main concern, > there may be a way to use a helper makefile like this for the Pd > external and adapt (arguments for) it to build the MaxMSP version: > https://github.com/pure-data/pd-lib-builder. > > I guess my concern is that I’m planning to move _all_ of my externals > over to Flext so I only have one API to think about. I would therefore need > a compelling reason to make an exception. > > BTW, I’m planning to support a wider range of F0 detection methods, > including at some point your own Helmholtz algorithm. > > best, > > Jamie > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list