numchuck 0.2.0

Changes since the last Release

Changed

• Upgraded ChucK core to 1.5.5.9-dev (chai) (thirdparty/chuck/): Updated the vendored ChucK to the current development build. Required one binding-level adjustment, noted under Fixed below.

• Pinned PdPatch's libpd dependency to a release tag (thirdparty/chugins/PdPatch/CMakeLists.txt): The FetchContent_Declare for libpd now pins GIT_TAG 0.16.0 (with GIT_SHALLOW TRUE) instead of tracking the moving master branch. libpd 0.16.0 bundles pure-data 0.56-3 via its pinned submodule. This makes the build reproducible and fixes a configure-time failure where master advancing upstream left the cached libpd checkout dirty and blocked the FetchContent git update step.

Fixed

• Windows access violation on teardown, regressed by the ChucK update (thirdparty/chuck/core/chuck.cpp, scripts/update.sh, scripts/patches/): The ChucK core update overwrote vendored source and dropped the numchuck local patch that adds a 50ms post-stop delay in ChucK::shutdown() for Windows (WASAPI/DirectSound threads need time to terminate before memory is freed; see docs/windows_fix.md). Without it, CI crashed with 0xC0000005 (exit 3221225477) during garbage-collection of Chuck instances between tests. Restored the delay, and added scripts/patches/0001-windows-shutdown-delay.patch plus an apply_chuck_patches step in update.sh that re-applies local chuck patches after every update and hard-fails if one no longer applies -- so this cannot silently regress again.

• Build break after ChucK core update: ChucK::shutdown() is now protected (src/_numchuck.cpp): The update reverted numchuck's local patch that had made shutdown() public (upstream keeps it protected; it is invoked by ~ChucK()). Rather than re-patch the header, the binding's shutdown method no longer calls it directly and instead only clears the Python-side chout/cherr and instance callbacks. VM teardown happens when the high-level Chuck.close() drops its sole reference to the instance, triggering the destructor -- preserving the prior teardown order (callbacks cleared before VM shutdown), and the restored 50ms delay still runs via the destructor on both the explicit-close and garbage-collection paths.