Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

HeadRush adapter: the easy second device, never actually started

Open
  • Is something wrong?
#33 11 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
devtools

Research direction

Start by reading fm9/adapter.py for the adapter contract and fm9/sim.py for the simulator model. The issue says the next step is a screen share to assess API stability and whether the adapter is wanted; confirm that scope before treating implementation as started. Done would mean an agreed, honest capability subset, a parameter registry, and a simulator, but this issue does not yet define or commit to that work.

Written by the indexing model from the issue text.

Description

Splitting HeadRush out of #17 with an honest status: this has never been started. The epic said "in flight" for weeks because it conflated @bschmalz81401's own HeadRush application with a ToneCommand adapter. They are different things, and only one of them exists.

@bschmalz81401 this is an invitation and a question, not a work order. Say no freely.

The reframe, because "move it into ToneCommand" is the wrong picture

You said you were clueless how this would work, and I think that is because the obvious reading is wrong. We are not asking you to move your app. Your HeadRush builder is a product: three platforms, its own UI, your own stack. Nothing here asks you to bin any of it.

A ToneCommand device adapter is a much smaller thing. It is one Python class implementing about a dozen methods against a device, plus a capability declaration saying what it can honestly answer. It has no UI. It does not replace anything. Your app and this adapter would talk to the same hardware and neither would know about the other.

So the two can simply coexist. Yours stays yours.

Why HeadRush and why now

Per #8, this is the easy second device: it exposes an open API, so there is no protocol reverse engineering at all. For contrast, the ToneX has taken three sessions of HDLC framing, checksum identification and hunting message types in a stripped binary (#23, #27) and still cannot be written to.

And the contract only became able to host a second device honestly last week. Before Capabilities landed in #26, it assumed every method worked everywhere, so an adapter for a device that cannot do something would have had to lie or fail. Now it can declare what it does and does not support, and the layer above degrades openly.

ToneCommand supports exactly one device today. That is the real reason to do this.

What the adapter actually is

fm9/adapter.py is the contract. The surface is roughly:

status_dump()        current blocks/bypass/channel from an honest read path
current_preset()     (number, name) or None
select_preset(n)
set_scene(n)         declare has_scenes=False if the device has no such concept
set_bypass(id, bool)
set_channel(id, n)
set_param_display(spec, value)    verified write: settle, read back, report
set_param_ordinal(spec, n)
bulk_read(id)
slot_name(n)         a stored name read WITHOUT selecting the slot
is_slot_empty(n)
store_preset(n)      whitelisted and confirmation gated
capabilities()       what this device can actually answer
close()

You do not have to implement all of it. That is the entire point of Capabilities: declare read_path, verifies_writes, has_scenes, stores_presets honestly, and the layer above adapts instead of assuming. A partial adapter that tells the truth is worth far more than a complete one that guesses.

Also needed alongside it: a parameter registry mapping HeadRush's blocks and parameters to names the planner can reason about, and a simulator so it is testable without hardware. fm9/sim.py is the model, including its habit of naming undecoded territory rather than pretending.

The honest asks

  1. Do you want this at all? You already have a working tool for this device. Building a second interface to it may be uninteresting, and that is a completely fine answer.
  2. Is the HeadRush API stable and documented enough for someone without the device to review the result sensibly? The maintainer has no HeadRush, which makes you the only person who can verify anything here.
  3. Would it be better as data rather than code? Your NAM captures, your IR work and the Big Sky matching idea might do more for this project through #18 than an adapter would. If you would rather spend the time there, say so.

The screen share you asked for is the right next step for all three of these. This issue exists so there is something to point at, not to commit you to anything.

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from monzta1/ToneCommand

All issues in monzta1/ToneCommand

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.