Comment by ~cannam on ~breakfastquay/rubberband
Committed, thank you!
REPORTED RESOLVED FIXED
Comment by ~cannam on ~breakfastquay/rubberband
Nice, thanks.
Is there a compelling reason to lookup and use the C compiler for this, rather than check with the known C++ compiler? (Since the latter is what will be used to build the file that uses sincos.)
Ticket created by ~cannam on ~breakfastquay/rubberband
A helpful correspondent writes:
Hello, I have built rubberband with new meson build system.
Then I found that installed packageconfig file for macOS is still need to edit after installation.
That is:
Libs: -L${libdir} -lrubberbandI have to add "-framework Accelerate" like below:
Libs: -L${libdir} -lrubberband -framework Accelerate
Comment by ~cannam on ~breakfastquay/rubberband
Actually added it to the main build file, as an optional target (with custom targets for the Java stuff).
REPORTED RESOLVED FIXED
Comment by ~cannam on ~breakfastquay/rubberband
A comparison with single-precision fftw is in the regression testing queue
Turns out the comparison can't meaningfully be made - even in single-precision mode, fftw preserves the full precision of its input (i.e. the result of a forward-inverse transform pair is identical to the input) while kissfft suffers rounding error from intermediate floating-point operations. I guess that means fftw is using double-precision behind the api.
Comment by ~cannam on ~breakfastquay/rubberband
That still leaves the question of why the kissfft build gave different results when 1.9 was compiled with the new build system vs the old
I just rebuilt and re-ran both cases, and the differences are not there. I must have misinterpreted something previously.
So the only open question is whether the slightly increased sensitivity in the transient detector (caused by the fix to incorrect float length accumulator mentioned above) is actually acceptable. I think it is, but I'll do a cautious review.
Ticket created by ~cannam on ~breakfastquay/rubberband
This is currently not handled by Meson - in future I imagine it may be, but for now dig out the relevant parts of the old Makefile and stick it in say
otherbuilds/Makefile.jni
Comment by ~cannam on ~breakfastquay/rubberband
Reviewing the kissfft results (1.9 vs now, when both using the new build system) in light of the observation about resamplers above, it turns out that the differences are also entirely in pitch changes. So the code itself is consistent between the two.
The difference between fftw and kissfft results can I think be mostly explained by the fact that fftw is double precision and kissfft (as RB uses it) single. A comparison with single-precision fftw is in the regression testing queue, but it had to wait on a fix to #13. The difference was exaggerated because of an incorrect float-length accumulator for double-length detection function in
HighFrequencyAudioCurve::processDouble, fixed in commit:ca4e83be584d.That still leaves the question of why the kissfft build gave different results when 1.9 was compiled with the new build system vs the old.
Comment by ~cannam on ~breakfastquay/rubberband
Fixed in commit:6bb8f42aac32 - incorrect casts in double-only/single-only cases.
REPORTED RESOLVED FIXED