Epic K: Captures as a cross-device adapter primitive
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- backend-api-design
Research direction
Start with the adapter contract in #17 and kb/TONEX_PROTOCOL.md, then read child stories #162 and #163 to understand the primitive and ToneX scope. Done means the capture-slot contract and ToneX mapping are covered; ToneX install is explicitly gated on #27, while Fractal and HeadRush implementations are out of scope.
Written by the indexing model from the issue text.
Description
Three devices in scope play captures: the ToneX Pedal (tone models, already a capture player, see kb/TONEX_PROTOCOL.md), Fractal (the NAM block from Epic I once it ships), and whatever the HeadRush adapter turns out to support. Today the adapter contract (#17) has no notion of a capture: each device's capture path would be its own special case. This epic adds one primitive, "capture slot", to the adapter contract so the intake and classification work from Epic I (read .nam metadata, decide whether a cab is needed, level-match by stated dBu) is written once and every adapter only implements install, list and remove for its own slots.
Small on purpose: the primitive and the ToneX mapping. Fractal's implementation lands under Epic I when firmware exists; HeadRush is a follow-up once its capture surface is verified on hardware, not assumed.
Child stories
- #162 K1 - Adapter contract: a capture-slot primitive (list, install, remove, capabilities)
- #163 K2 - ToneX through the capture primitive: list and capabilities now, install only when #27 clears
- Dominant language
- Python
- Stars
- 7
- Forks
- 3
- Avg merge
- 2h 17m
- Merged PRs (30d)
- 49
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from monzta1/ToneCommand
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
monzta1/ToneCommand#293 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
monzta1/ToneCommand#268 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
monzta1/ToneCommand#269 ·
Maintainers usually reply within 1 day
-
bug device
Difficulty 4/5 3-5 days Newbie friendliness 12/100
monzta1/ToneCommand#250 · 1 comment ·
Maintainers usually reply within 1 day
-
bug device
Difficulty 4/5 3-5 days Newbie friendliness 18/100
monzta1/ToneCommand#241 · 2 comments ·
Maintainers usually reply within 1 day
All issues in monzta1/ToneCommand
Similar issues
-
Support .aac audio uploadsPossibly taken @julien731 claimed this today. Openfeature
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
nimblehq/audio-transcriber#153 ·
-
help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
antonyrag/ragleap-core#1062 ·
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
gke-labs/kube-agents#4321 ·
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Git-Hospital/githealthcheck#61 ·
Maintainers usually reply within 1 day
-
changelog investigate
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ramnes/notion-sdk-py#433 ·