Migrate to meson, vcpkg and cibuildwheels - #432

Add test sounds

…directory

…luding the current build directory

…ot for aubio.h

…atic library for portable wheels

…and improve compiler detection

- Modified python/meson.build to set CC environment variable when running gen_external.py
- Updated gen_external.py to prefer gcc/clang over cl.exe and add better error handling
- This ensures the script uses the same compiler Meson is using, with proper environment setup

- Changed artifact naming from 'cibw-wheels-{arch}' to 'wheels-{os}-{arch}'
- Each platform's wheels now uploaded as separate artifacts for easier testing
- Example artifacts: wheels-ubuntu-latest-x86_64, wheels-windows-latest-AMD64, etc.
- Added compression-level: 0 (wheels are already compressed)
- Updated publish jobs to download wheels-* pattern and sdist separately
- Makes it much easier to download and test specific platform wheels

…anagement

**Problem**:
- Windows wheels missing rubberband, ffmpeg (only basic aubio DLL)
- macOS wheels missing ALL optional dependencies (no vcpkg/brew setup)
- Linux wheels missing rubberband, ffmpeg

**Root Cause**:
- vcpkg.json only had basic deps: libsndfile, libsamplerate, fftw3
- macOS had no dependency installation configured at all
- Linux repos have limited packages available
- Windows vcpkg wasn't being invoked or paths weren't set

**Solution**:

1. **vcpkg.json**: Added rubberband and ffmpeg
   - ffmpeg configured minimally (avcodec, avformat, swresample)

2. **pyproject.toml** - Platform-specific dependency installation:

   **Linux** (AlmaLinux/RHEL via yum):
   - Enable EPEL and PowerTools/CRB repos for extra packages
   - Install: libsndfile, libsamplerate, fftw3
   - Try ffmpeg-free if available (RHEL 9+)
   - Note: rubberband not available in standard RHEL repos

   **Windows** (vcpkg):
   - Run vcpkg install before build
   - Set CMAKE_PREFIX_PATH and PKG_CONFIG_PATH
   - Installs: libsndfile, libsamplerate, fftw3, rubberband, ffmpeg

   **macOS** (Homebrew):
   - NEW: Install via brew (was missing entirely!)
   - Installs: libsndfile, libsamplerate, fftw3, rubberband, ffmpeg, pkg-config
   - Uses native Accelerate framework for FFT/DCT (no FFTW needed but included)

3. **meson.build**: Improved vcpkg integration
   - Better tracking of vcpkg status
   - Windows-specific debug lib paths

**Expected Results**:
- Windows: Full-featured wheels with all dependencies statically linked
- macOS: Full-featured wheels using Homebrew deps + Accelerate + CoreAudio
- Linux: Best-effort wheels (core deps always, ffmpeg if available)
- All wheels are portable with bundled dependencies

…ironment variable

Set macOS deployment target dynamically and update pyproject.toml env…

…ith specific deployment targets

…kg dependencies

…ctly adding link argument

Upstream settled aubiogh-318 by defining rolloff as the 0-based index of the
bin that reaches 95% of the energy (1e35340, c2c3192, picked above),
the reverse of the bin count the fork's previous commit restored. Follow
upstream, so aubio-ledfx and aubio agree: the bounded loop stays, the C
test now expects 0 for energy in the first bin and length - 1 for the
last, and the specdesc.h documentation describes the index.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

Records upstream's history as merged, so the fork is no longer reported
behind and the next sync only has to look at newer upstream commits. The
tree is unchanged (-s ours): every upstream code, test and doc change
that applies to this fork is cherry-picked in the commits above, and
the rest is intentionally not taken:

- waf, Xcode and Apple cross-build targets (watchOS, tvOS, visionOS,
  iOS architectures, macOS minimums), doxygen and Makefile tweaks:
  this fork builds with meson and cibuildwheel;
- upstream's initial meson and CMake builds and their scripts: this
  fork's meson build is its own and more complete;
- [sampler] uri termination (e559ff1), [sink_flac] SWAPS (b34ed46),
  the raw-string regexes (46f7846), the ffmpeg 8 build fix (3c04fb8)
  and the chlayout options (0a93f70): already in the fork;
- [source_avcodec] get_duration condition (146f701): superseded by the
  fork's rewrite of that function (aubio#322);
- [py] relax cvec.phas precision (2018ff3): superseded by c3a4ec4.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

Windows wheel builds took 30+ minutes against 6 with a warm cache: every
cache had expired (GitHub evicts caches unused for 7 days), so Windows
rebuilt FFmpeg, rubberband, FFTW and the codec libraries from source with
MSVC. The cache design made this likely and had a correctness hole:

- vcpkg.json had no builtin-baseline, so port versions came from whatever
  vcpkg the runner image shipped (and Linux cloned vcpkg master): builds
  were not reproducible, and the cache key did not change when versions
  did.
- The whole vcpkg_installed tree was one cache entry, so any vcpkg.json
  change rebuilt everything.
- Windows ran `if not exist vcpkg_installed vcpkg install`: a prefix
  (restore-keys) hit restored an older tree and skipped the install, so a
  dependency added to vcpkg.json would silently be missing from the wheel.

Now:
- vcpkg.json pins builtin-baseline (the 2026.07.29 release), and every
  platform checks vcpkg out at exactly that commit (treeless clone).
- vcpkg's own binary cache (one archive per package, keyed by its ABI
  hash) is kept in an actions cache on all platforms; on Linux it reaches
  the manylinux container through cibuildwheel's /host mount. A warm run
  only unpacks archives, and a vcpkg.json change rebuilds just the
  packages it touches.
- vcpkg install always runs.
- CI also runs weekly on main, which keeps main's caches (which pull
  requests restore) from expiring and catches runner image changes early.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

The cold Windows log showed sleef built twice: 7.2 min for x64-windows
and 6.5 min for x64-windows-release. rubberband's sleef dependency needs
sleef's code generators for the host triplet, and vcpkg's default host
triplet (x64-windows, debug + release) differs from the release-only
target, so sleef was compiled a second time just for those tools.
--host-triplet=x64-windows-release makes them the same.

Cold Windows dependency build, from that log: ffmpeg 11 min, sleef
7.2 + 6.5 min, fftw3 2 min, the other nine packages about 2.5 min.

Correction to "stop building FFTW on Linux for nothing": on x64 Windows
vcpkg's rubberband port uses sleef, not FFTW (FFTW is only for ARM/x86
Windows and macOS), so removing the top-level fftw3 entry also stops
building it on Windows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

The macOS wheels failed building rubberband 4.0.0: with Xcode 26.6's
libc++, src/common/mathmisc.h uses size_t without including a header
that declares it. vcpkg fixed the port (4.0.0#2, fix-size-t.patch,
breakfastquay/rubberband#131) in 173a2013, after the 2026.07.29 release
this was pinned to, and no release contains it yet.

That commit's baseline also moves FFmpeg from 8.1.2 to 9.0.1. FFmpeg 9
is a major API change for source_avcodec, unrelated to this fix, so
overrides keep ffmpeg 8.1.2#3 and its ffmpeg-bin2c 8.1.1 tool. Other
dependency moves: mpg123 1.33.4 -> 1.33.7, opus 1.5.2 -> 1.6.1 (Linux
only), zlib 1.3.2#1 -> #2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

Moving builtin-baseline to 173a2013 for the rubberband fix also moved
FFmpeg to 9, which needed an `overrides` entry to hold it at 8.1.2.
vcpkg resolves an override by reading the old port out of git history,
and the treeless clone fetches that lazily; on Windows that fetch runs
from vcpkg's sanitised environment and fails with "Could not resolve
host: github.com", so every Windows wheel build failed before compiling
anything.

Instead, stay on the 2026.07.29 release and carry vcpkg's fixed
rubberband port (4.0.0#2, a verbatim copy from 173a2013) in
vcpkg-ports/, declared as an overlay in vcpkg.json. Nothing needs git
history, every other dependency is back at the release's version, and
the overlay is dropped when a release includes the fix. prek skips
vcpkg-ports/: trimming trailing whitespace would corrupt the patch's
context lines.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

…ws with MSVC

Wheels are meant to be a complete, modern aubio for anyone who needs one,
so every platform now ships every feature that works in a Python package.
The CI logs (meson's summary, now printed) showed what each wheel had:

- Linux had no FFmpeg and no rubberband. vcpkg.json excluded both for
  "PIC issues with static linking", but vcpkg's FFmpeg port configures
  with --enable-pic and the Linux triplets build everything with -fPIC.
  Both are now built on every platform; a static rubberband also needs
  the C++ runtime, so Linux links libstdc++ as macOS links libc++.
- No wheel could read or write MP3: libsndfile was built without its
  mpeg feature (mpg123 and LAME were only installed, on Linux). It is on
  everywhere now, and libvorbis and libflac, which aubio's own sinks use
  directly, are listed for every platform instead of Linux only.
- Windows wheels were compiled by Strawberry Perl's MinGW gcc, the first
  C compiler on the runner's PATH, against MSVC-built vcpkg DLLs. meson
  now gets --vsenv, so CPython, the extension and its DLLs share one
  toolchain and C runtime.
- Windows also ignored pkg-config (Strawberry's, which meson rejects) and
  Linux pointed PKG_CONFIG_PATH at a literal "{project}" (cibuildwheel
  doesn't expand it in environment tables), so both found libraries by
  name only, without their transitive dependencies. Windows now uses
  vcpkg's own pkgconf and Linux the container's real /project paths;
  vcpkg's static .pc files carry every transitive library.
- delvewheel warned that rubberband-3.dll and sleefdft.dll were built
  with a newer MSVC toolset (14.51) than the msvcp140.dll it found
  (14.40); an older msvcp140.dll can crash newer C++ code. The wheel now
  bundles msvcp140.dll from the Visual Studio that built them.
- Linux and macOS built vcpkg's debug libraries too: VCPKG_BUILD_TYPE
  was set in the environment, which vcpkg ignores. The Linux triplets
  now set it, and macOS uses vcpkg's arm64/x64-osx-release triplets.

python/README.md described FFTW (never used), Python 3.8-3.14 and Linux
without FFmpeg or rubberband; it now lists what the wheels contain.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

Every pull request built all five wheel jobs, even for a README change,
and a cold Windows or macOS job takes 25 minutes. A Plan job, after
LedFx's, now decides what to run:

- prose, docs, other workflows and bot config: lint only;
- one platform's [tool.cibuildwheel.<platform>] table (the old and new
  pyproject.toml are compared table by table), its vcpkg triplets or
  its platform-only sources: that platform's wheels;
- Python bindings and tests, vcpkg.json and its overlay ports: every
  wheel, without the C tests;
- the C library, its tests and meson.build: the C tests and every
  wheel. meson.build is one file for all platforms, so it can't be
  split by platform the way pyproject.toml's tables can;
- build.yml itself, or any path it doesn't know: everything.

Stacked pull requests follow LedFx: one with another open PR on top
builds Linux x86_64 only, and the top of the stack builds everything.
Pushes to main and tags, the weekly run and manual runs always build
everything, so a release never depends on the plan.

Paths filters can't do this: a workflow they skip never reports, and
the required "CI passed" check would wait forever. Jobs the plan skips
report "skipped", which CI passed now accepts; anything that ran must
have succeeded. The version check moves into the plan job, which
already reads the same files.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

The Windows wheels were built with MinGW, which has both headers; MSVC
has neither. strutils.c includes <strings.h> only for strncasecmp,
which Windows builds already map to _strnicmp (HAVE_WIN_HACKS), so it
is included only when that mapping isn't used.
timestretch_rubberband.c included <pthread.h> behind a HAVE_THREADS it
defined itself, and nothing in the file uses threads: removed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

mpg123 (libsndfile's MP3 decoder, now built everywhere) failed at once
on the aarch64 wheel: it asks CMake whether the CPU has an FPU, CMake
reads /proc/cpuinfo, and aarch64 lists "fp" rather than "fpu". mpg123
then picks fixed-point maths with a floating-point decoder and stops
with "Bad decoder choice together with fixed point math!". Reproduced
by cross-compiling 1.33.4 for aarch64: HAVE_FPU=0 fails exactly so,
HAVE_FPU=1 builds. Every aarch64 CPU has an FPU, and vcpkg's port
patch takes HAVE_FPU from the triplet for this case.

vcpkg only prints the paths of a failed port's logs, which are gone with
the manylinux container, so the Linux before-all now prints their tails.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…mbolic

The first Linux wheel build with FFmpeg failed to link: FFmpeg's x86
inline assembly refers to its own constants with PC-relative relocations
(R_X86_64_PC32 against ff_pw_9 in vc1dsp_mmx.o), which a shared object
only accepts when the symbol binds locally. That, not -fPIC, is the
"PIC issue" that kept FFmpeg out of the Linux wheels. vcpkg's FFmpeg port
documents the fix for its static Linux libraries in a shared library,
-Wl,-Bsymbolic, which FFmpeg's own shared builds also use.

Reproduced with a static archive whose assembly loads a global constant
PC-relatively: linking it into a shared object fails with "final link
failed: bad value", and links with -Bsymbolic without text relocations.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

…acOS 13.3+

aubio_priv.h defined ACCELERATE_NEW_LAPACK unconditionally (upstream
8098196, to silence deprecation warnings). Accelerate then declares
cblas_* with new symbol names (_cblas_sdot$NEWLAPACK, ...) that only
exist from macOS 13.3. The published 0.4.11 macOS wheels reference
_cblas_sswap, _cblas_sdot and _cblas_scopy$NEWLAPACK while being tagged
for macOS 10.15 (Intel) and 11.0 (Apple Silicon), so they can't load on
macOS older than 13.3. The wheel build warned about it each time
(-Wunguarded-availability-new in mathutils.c).

The new interface is now used only when the deployment target is macOS
13.3 / iOS 16.4 or newer; older targets get the classic cblas symbols,
which those systems have. Checked with clang's predefined targets:
10.15, 11.0, 13.2 and iOS 16.0 select the classic interface, 13.3, 15.0
and iOS 16.4 the new one. ACCELERATE_LAPACK_ILP6, a misspelling of
ACCELERATE_LAPACK_ILP64 that did nothing, is dropped.

-Werror=unguarded-availability-new on macOS makes any future unguarded
use of an API newer than the deployment target a build error instead of
a wheel that fails to import.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

…bug info

With static FFmpeg and rubberband linked in, each Linux wheel grew from
5 MB to 88 MB. vcpkg's static libraries are built with debug information,
and ELF linking copies it into the extension; meson-python doesn't strip
(it ignores meson install's --strip). The wheel builds now link with
-Wl,--strip-debug on Linux and -Wl,-S (no debug information) on macOS,
whose published wheels were already 22-24 MB with static FFmpeg. Local
builds keep their debug information: only the cibuildwheel tables set it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

…dfx-upstream-sync

Mend only runs Renovate on a fork in autodiscover mode when the fork's own
renovate.json sets forkProcessing, so a shared preset cannot enable it.
The vcpkg builtin-baseline pins every native dependency in the wheels; a
person reviews a move and checks whether the rubberband overlay is obsolete.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T34aerZWk6JNrHKWd4YcrN

fix(renovate): enable fork processing, review vcpkg baseline bumps

…umerics tool to prove it (#61)

* fix: copy file paths safely and allocate with calloc's real argument order

Every source, sink and the sampler copied their path with
strncpy(dst, path, strnlen(path, PATH_MAX) + 1) into a buffer of
strnlen + 1 bytes. A path of PATH_MAX characters or more filled the
buffer without a terminating NUL, so the next "%s" (every error message
prints the path) read past it, and the file opened was a truncated path,
another file. gcc's -Wstringop-truncation flagged all ten. They now
share aubio_str_copy_path(), which rejects such a path with an error
and otherwise copies it whole. aubio_sampler_load also left o->source
pointing at the source it had just deleted when loading failed.

AUBIO_NEW and AUBIO_ARRAY called calloc(size, 1) and calloc(n * size,
1). calloc(n, size) is the documented order, and it checks n * size for
overflow, which the hand-multiplied form can't (gcc 14
-Wcalloc-transposed-args).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* fix(python): give every CPython slot its exact signature, and build warning-free

CPython calls each slot through a function pointer of the slot's type.
Several of ours had a different number of parameters, which C leaves
undefined: it works with the usual x86 and ARM calling conventions, and
traps under WebAssembly or clang's control-flow integrity:
- every tp_dealloc took (self, PyObject *unused); destructor is (self);
- every tp_call took (self, args); ternaryfunc is (self, args, kwds).
  sink and source use the same function as their METH_VARARGS/NOARGS
  "do" method, so their tp_call is now a three-parameter wrapper;
- cvec's tp_repr took (self, unused); reprfunc is (self).
gcc's -Wcast-function-type reported them among the noise.

The rest of the extension's -Wextra warnings were noise that hid those:
- parameters a slot's signature requires but the code doesn't read are
  marked Py_UNUSED, CPython's own macro for them;
- type objects use designated initializers (.tp_name = ...) instead of
  48 positional fields, most of them 0, so none is left implicit and the
  meaning of each entry is visible;
- method and member table sentinels are {0}, which gcc and clang accept
  as a complete initializer, instead of {NULL}.
The generator (gen_code.py) emits the same, so the generated types match.

sink and source copied their path into an unterminated buffer when it
was PATH_MAX characters or longer, and didn't check the allocation: they
now copy the whole path (the C library rejects one it can't open).

gen_external.py ran MSVC's preprocessor without /nologo, and missed it
behind a compiler wrapper (ccache cl), so cl's banner was reported as
"preprocessor produced errors or warnings" on every Windows build.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* build: POSIX.1-2008 everywhere, pkg-config-only lookups, MSVC's CRT advice off

- _POSIX_C_SOURCE was 200112L for aubio and 200809L in Python.h, so
  every file of the extension warned about the redefinition. It is
  200809L for both now. That also declares mkstemp, whose hand-written
  declaration in tests/utils_tests.h had always been wrong (returning
  char, not the int file descriptor): removed.
- The Linux lookups of libsndfile's codec libraries, and the JACK
  lookup, fell back to CMake whenever pkg-config missed. Meson then
  printed warnings about generator expressions in vcpkg's CMake configs,
  and asked CMake for "mpg123", whose pkg-config name is libmpg123.
  They use pkg-config only, with the right name.
- MSVC deprecates the standard C and POSIX functions (strncpy, fopen,
  strdup) in favour of non-portable _s and _-prefixed variants;
  _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE turn that advice
  off for this portable C code.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* test(python): close sinks before deleting their files, expect pitchshift's warning

- test_read_and_write and test_read_and_write_multi deleted the file
  their sink was still writing: Windows can't delete an open file, which
  was most of the 169 test warnings there, and the WAV header was never
  finished, so the tests never checked a complete write.
- test_on_zeros sweeps the transposition down to where rubberband has
  less than a block ready; aubio pads with zeros and warns. The test now
  expects that warning instead of leaving it in every summary.
- source and sink reject a path PATH_MAX characters or longer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* fix: design A/C-weighting for any samplerate, and fail cleanly instead of crashing in pitch mcomb

The A- and C-weighting filters were hard-coded coefficient tables for
eleven sample rates; any other rate returned an error, and pitch's mcomb
mode then dereferenced the NULL filter (a segfault at e.g. 30000 Hz).

- aubio_filter_set_analog: bilinear transform of an analog transfer
  function into the filter's coefficients.
- a_weighting/c_weighting: build the IEC 61672 analog prototypes and
  transform them at the requested rate. At the rates the tables covered,
  the new coefficients match the old ones within 7e-15.
- new_aubio_pitch checks every allocation and frees through a NULL-safe
  del_aubio_pitch on failure.
- tests: gain at 1 kHz checked across rates; mcomb at 30000 Hz.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* fix(python): build the bindings in double precision when the library is

With -Ddouble=true the library's smpl_t is a double, but the extension
was compiled without HAVE_AUBIO_DOUBLE (float_type float32) and the
generated wrappers parsed smpl_t arguments as floats: every getter and
setter of a generated object read or wrote garbage (get_power() returned
5e-315), and 20+ Python tests failed.

- the extension gets the library's public defines (aubio_public_c_args)
- gen_external.py takes --double, which meson passes in double builds

The Python suite passes in double precision too.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* fix: intentional float precision, and the bugs implicit conversions hid

smpl_t math was written with double literals and double PI, so a float
build computed some of it in double and narrowed it back implicitly, at
375 places (clang -Wimplicit-float-conversion -Wimplicit-int-float-conversion
-Wshorten-64-to-32 -Wfloat-conversion; MSVC's C4244/C4305). Each site is
now one of two things:

- per-sample math stays in smpl_t: integer or smpl_t constants, SMPL_PI
  and SMPL_TWO_PI, typed ROUND/DB2LIN/KILL_DENORMAL/CEIL_DENORMAL
- setup math (windows, DCT matrices, FFT twiddles, filterbanks, weights,
  rates) is computed in double and narrowed once, explicitly

aubio_unwrap2pi stays in smpl_t with a split 2pi (Cody-Waite), as
accurate as its double version. -Wfloat-conversion is now on for gcc and
clang so new implicit narrowing is reported, as MSVC does.

Bugs this turned up:
- pitch mcomb: bufsize / hopsize was an integer division, so the phase to
  bin factor was wrong when the hop doesn't divide the window (LedFx's
  4096/500)
- pitch schmitt: a full-scale sample overflowed its 16-bit buffer
- beattracking: the Rayleigh parameter (the 120 bpm prior) was stored as
  an integer
- onset/tempo: delays set in seconds or ms were truncated, now rounded;
  the start-of-file onset offset was an integer quotient
- source_wavread: seeks went through a long, 32 bits on Windows; now a
  64-bit fseeko/_fseeki64 (AUBIO_FSEEK)
- source_sndfile: durations past 2^31 frames overflowed an int; the
  resampling ratio is kept in double
- a strict-ANSI hack defined floorf as floor, so FLOOR was a double
  function in float builds; strnlen hack gone too (POSIX.1-2008)
- sink_vorbis, sink_wavwrite, fvec/fmat_rev, statistics slope (closed
  form), tss (selection without float multiplies)

Measured against a double-precision build of the same code, with the
numerics harness: windows 1.8e-7 -> 3e-8 max relative error, dct
3.3e-6 -> 2.2e-7, slaney filterbank 3.7e-6 -> 6e-7, specacf/fcomb/
schmitt pitch errors gone, onset/pitch/tempo means equal or better;
phase-based onset functions on noiseless tones stay as chaotic as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* test: numerics tool to record, compare and score aubio's outputs

scripts/numerics/numerics.py:
- record: every output of every algorithm on fixed signals, at 44100/512/
  2048 and LedFx's 30000/500/4096, to an .npz
- compare: how far one recording moved from another; with --ref (a
  double-precision build of the same code) each one's error against it,
  better or worse per output, and events as F-measures
- accuracy: onsets (F, 50 ms), beats (F, 70 ms), tempo (4%, and with
  octave errors allowed), lock time after tempo changes, pitch (50 cents),
  against ground truth

scripts/numerics/signals.py: seeded signals with exact ground truth. PR
#34's drum benchmark and tempo sections, fixed: the kick's pitch drop is
integrated, the noise is seeded, every beat and hit is in the ground
truth, and the accelerando's tempo really ramps.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

* fix(io): source_apple_audio fails when its path is rejected

aubio_source_apple_audio_open jumped to its exit with err still noErr
when the path was too long (or the buffer list couldn't be allocated),
so new_aubio_source_apple_audio returned a source with no path, and the
Python binding returned it with the error already raised (SystemError in
test_path_too_long on macOS).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TER4uCd2AQ9Qzo3AAPsuSa

---------

Co-authored-by: Claude <noreply@anthropic.com>

…time, latency taken back (#63)

Co-authored-by: Claude <noreply@anthropic.com>

Co-authored-by: ledfx-automation[bot] <334822522+ledfx-automation[bot]@users.noreply.github.com>

Uses the shared release-ci version-scope action (v0.4.2) so release-please PRs and their merges skip the C tests and wheel builds. The plan reads the action's version-only output, clears it when a change touches the libtool ABI numbers in VERSION, and ci-passed fails only when a job the plan selected was skipped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>