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

AM4 adapter: Fractal's smallest rig, possibly the smallest adapter

Open
  • Is something wrong?
#41 0 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
22/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
python
Domain
backend

Research direction

This is a tracking issue for a new AM4 adapter matching the existing fm9/adapter.py contract, with a simulator like fm9/sim.py, plus registry and docs in docs/PROTOCOL.md / docs/PROTOCOL-CONTRIBUTIONS.md. First work is capturing AM4-Edit traffic to identify the protocol family and model byte; done means honest Capabilities, a green simulator suite without hardware, then write-plus-readback on a real AM4 with firmware logged. The maintainer has no AM4, so captures and hardware verification belong to whoever takes it.

Written by the indexing model from the issue text.

Description

enhancement help wanted

Tracking issue for an AM4 adapter, in the same spirit as the FM3 one (#40): what the work is, what "done" means, and what each side owes the other. Whoever wants it, comment and it is yours.

What the AM4 is, for anyone landing here cold

Fractal's compact amp modeler, announced November 2025: Axe-Fx III-generation modeling in a four-footswitch pedal. 104 presets, each a fixed mini-rig of four blocks with four scenes and four channels per block, MIDI plus 4x4 USB audio, dual expression jacks, and its own editor (AM4-Edit, with integrated Fractal-Bot). Announcement: https://www.fractalaudio.com/downloads/manuals/AM4/251124-Fractal-Audio-Systems-Announces-the-AM4.pdf and product page: https://shop.fractalaudio.com/products/am4-amp-modeler

Why it is interesting here

It is the cheapest door into Fractal's modeling, which makes it the device a lot of first-time buyers will actually own, and its rig model is a strict subset of what ToneCommand already reasons about: scenes, channels, per-channel parameters, named presets. Four fixed blocks means the entire grid/cable problem that consumed months of FM9 protocol work (docs/PROTOCOL-CONTRIBUTIONS.md items 5, 7, 11, 12) may simply not exist on this device. If the editor protocol cooperates, this could be the smallest adapter in the family.

The open questions, which ARE the first work items

Unlike the FM3 (#40), which shares the decoded gen-3 editor protocol, nothing public says yet what AM4-Edit speaks. In order:

  1. Protocol family. Capture AM4-Edit traffic and establish whether it is the known gen-3 sysex family with a new model byte, a variant, or something new. AM4-Edit shipping with integrated Fractal-Bot hints at family lineage; hints are not findings.
  2. Model byte and command coverage. If gen-3: which byte, and which of the documented commands (scenes, bypass, channels, names, tempo, parameter reads/writes) answer. Every claim proven by write-plus-readback on the hardware, firmware version stated.
  3. The lying reads. Check which of the FM9's documented read quirks (zeroed GETs, stale asynchronous reads, display-name defaults) exist here. Assume nothing in either direction.
  4. Rosters. Amp/cab/effect complements differ from the FM9's; the adapter needs its own registry and grounding mapping under the same facts-only, cited, drift-guarded rules.

What the adapter then is

One class behind the existing fm9/adapter.py contract with an honest Capabilities declaration (four scenes, no free-form grid, whatever else is true), a parameter registry, and a simulator in the mold of fm9/sim.py, undecoded territory named rather than pretended. The safety layer - validation, confirmation, preset pinning, store whitelist, read-back verification - is inherited, never reimplemented. Rule zero is structural from day one: the transport whitelist keeps firmware and bootloader operations unreachable by construction.

Division of labor

The maintainer owns no AM4, so captures and hardware verification belong to whoever takes this, and their regression log is what review will ask for. In return: quick answers on the adapter contract, review with file-level findings, and protocol discoveries landing in docs/PROTOCOL.md with credit, exactly as the FM9 findings did.

Done means

  • Protocol family established from captures, written up whichever way it goes; a finding of "not the gen-3 family, here is what it is instead" is a full success for step one.
  • Adapter behind the existing contract, capabilities declared honestly, partial but truthful beats complete and guessed.
  • AM4 registry and simulator, full suite green without hardware.
  • Write-plus-readback verification on a real AM4, firmware version logged.
  • Rule zero demonstrated: no path to any message type outside the decoded surface.
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.