feat: Maniac Bounce delay

[kosmar]

Summary

• New WIP app Maniac Bounce (ID 48): MIDI/CV delay with dry-through, bounce pitch, and velocity LFO on dry + repeats.
• Main couples delay + decay; Alt bounce ±24 st; Third LFO rate+depth. Poly with same-pitch kill.

Test plan

• On hardware: MIDI in → delayed bouncing MIDI out, dry through
• Same pitch retrigger kills prior trail; NoteOff does not
• Third Vel LFO on dry and repeats; MIDI→CV Gate pulse-width wobble
• Mute ring-out / long Panic

Made with Cursor

[kosmar]

Written by an AI coding agent on @kosmar's behalf.

Force-pushed a Wave-1 scope cleanup onto this branch (single commit vs main):

• 4 files only: faderpunk/src/apps/<app>.rs, one mod.rs register line, docs/apps/<id>-<name>/manual.{json,md}
• No Configurator ManualTab, no tasks/*, app.rs, storage.rs, or libfp changes in this PR
• Shared helpers where needed are inlined in the app file (not feat: add shared app helper modules and libfp clock/brightness helpers #641)
• Clocked apps: clock drain + glob_ticks (no clock_ticker / mixed wait_for_event+MIDI in one task)
• No ParamStore::update / host param writeback (feat: let apps write back their own params and notify the host #640/feat: ParamStore::update polyfill without host push #647 stays separate)
• Voice MIDI uses blocking send_note_on().await for now; ready to adopt try_send_* from feat: add non-blocking note and CC senders for voice engines #639 after merge

Please re-run CI on this branch. Happy to adjust anything for review.

[ArthurGibert]

Hey @kosmar — two things, one about where this belongs and one about the manual format you're using.

Where it belongs: this looks like a great fit for faderpunk-community-apps, which just went public. New on-device apps are meant to land there rather than here directly — see CONTRIBUTING.md's "Standalone companion tools" section, and the pointer it promised once that repo was live.

Ran maniac_bounce.rs against the actual submission gate (pr-scope-check.sh) — clean, no unsafe code, no panics, no MAX11300/storage bypass, no un-yielding loop — and did a real cargo build against current main with it dropped in, which passed too. It does have 11 .unwrap()/.expect() calls without a justification comment, which the gate soft-flags for human judgment rather than blocking (same treatment some existing official apps get) — worth a look before resubmitting, not a blocker.

About docs/apps/48-maniac-bounce/manual.{json,md}: this one's on us, not you — it was listed as a sanctioned option in CONTRIBUTING.md/the scope-check script without anyone actually verifying it was backed by real tooling, and it wasn't: nothing in the configurator reads it (confirmed against #606; its entry doesn't show up on the /#/manual page at all). You followed the policy as documented — the policy was wrong. Filed as #656, and #657 has already removed it as an option here. So faderpunk-community-apps isn't just a better fit organizationally — right now it's the only place this content would actually end up visible anywhere.

To resubmit there: just the app file itself (no mod.rs/registration changes — those are generated), a community app ID in the 100+ range, and a manual-tab.json entry built from your existing manual.{json,md}. Most of it maps over directly (manual.md is the entry's text field verbatim; name→title; description/color/icon/params/storage and most of channels are already the same shape) — but the schema also has fnPlusShiftTitle/ledTopPlusShift/ledBottomPlusShift-style fields for documenting combined Shift/Fn/Button behavior, which your format doesn't have dedicated slots for; where that's described inline in fnDescription/ledTop today, it'd need pulling out into those fields for parity with how official apps are documented. Happy to help with the conversion if useful. Whether/when to close this one is up to you or a maintainer — just flagging where it belongs.

[kosmar]

Moving this to faderpunk-community-apps as requested: ATOVproject/faderpunk-community-apps#20

Closing here. App ID remapped 48 → 117 (community range).