~cannam

Trackers

~cannam/easyhg

Last active 6 months ago

#16 Detect lack of GNU sincos() in meson 6 days ago

Comment by ~cannam on ~breakfastquay/rubberband

Committed, thank you!

REPORTED RESOLVED FIXED

#16 Detect lack of GNU sincos() in meson 6 days ago

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.)

#15 Generated pkg-config file for macOS lacks Accelerate framework a month ago

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} -lrubberband

I have to add "-framework Accelerate" like below:

Libs: -L${libdir} -lrubberband -framework Accelerate

#14 Add build file for JNI interface a month ago

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

#10 Regression failures in c9df6c152612 relative to v1.9 a month ago

on ~breakfastquay/rubberband

REPORTED RESOLVED FIXED

#10 Regression failures in c9df6c152612 relative to v1.9 a month ago

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.

#10 Regression failures in c9df6c152612 relative to v1.9 a month ago

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.

#14 Add build file for JNI interface a month ago

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

#10 Regression failures in c9df6c152612 relative to v1.9 a month ago

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.

#13 "NaN encountered" a month ago

Comment by ~cannam on ~breakfastquay/rubberband

Fixed in commit:6bb8f42aac32 - incorrect casts in double-only/single-only cases.

REPORTED RESOLVED FIXED