KN-90T Toneline

Projected MSRP (1990): $179.95 (acknowledged internally as likely too high) Prototypes produced: Unknown; fewer than the Statline. No surviving unit publicly confirmed. Source: Notion — KN-90T Toneline Imported: 2026-04-26 Related: future-concepts.md, kn90s-statline.md, kn92-gridline.md, Kinoshita Electronics Consortium

---

The Toneline was a portable music composition and performance device targeting bedroom musicians, particularly teenagers and young adults already spending $200–400 on basic four-track cassette recorders.

Form Factor

Clamshell form factor returned but in landscape orientation — wider than the Deckline to accommodate a horizontal sequencer timeline on the display. The same Sharp 240×128 LCD panel was mounted sideways. All sixteen function keys retained, remapped to musical operations: loop definition, phrase placement, playback, note selection, voice assignment, tempo control. The numpad served double duty for pitch input (digits mapped across a selectable scale — chromatic, pentatonic, or major) and tempo/BPM entry.

Audio Subsystem

The most ambitious change: the Deckline’s Yamaha YM2149 PSG was replaced with a Yamaha YM2612 FM synthesis chip — the same chip that powered the Sega Genesis. Six FM voices plus a PCM channel. The difference in fidelity was substantial: rich, layered FM tones — electric pianos, synthetic brass, punchy bass, metallic percussion.

• Internal speaker upgraded to a 40 mm driver with a small passive radiator for improved low-frequency response.
• 3.5 mm line-out jack added alongside the headphone output for direct connection to an external tape recorder, boombox, or amplifier.

Interaction Model

The list-processing paradigm mapped naturally to music composition:

• A song is a list of patterns
• A pattern is a list of sequences
• A sequence is a list of notes
• LAMBDA defines reusable musical phrases (a bassline, a drum pattern, a melody) insertable at any position in an arrangement
• The LINK port enables two Tonelines to sync and play together over a serial cable — a portable 1988 jam session

Development Status (in fiction)

Less advanced than the Statline. The YM2612 integration was working and reportedly impressive — Edgeware’s audio programmer produced several demonstration compositions that circulated internally on cassette. However, the upgraded audio hardware, larger speaker, and landscape clamshell tooling pushed projected BOM cost beyond what the consortium could sustain at a viable consumer price point without new investment. Loop quantization and multi-deck LINK synchronization were still in development when the project was suspended.

Surviving Units (in fiction)

No Toneline prototype has been publicly confirmed to survive. The device is referenced in internal Kinoshita memos and product briefs recovered from the Edgeware founder’s papers when his estate was settled in 2011. The demonstration cassette tape of YM2612 compositions was reportedly among those papers, though its current whereabouts are unknown. Whether a working Toneline unit exists in a box in someone’s garage in Houston — where PacRim Display Technologies was headquartered — remains a matter of speculation among Deckline collectors.

---

Buildable design — 2026-07-04 pass

Scope: engineering, not fiction. This section is the buildable design for the modern Toneline reconstruction. It supersedes the earlier Batch-8 platform framing (which pinned the Toneline to the KN-86 stack verbatim — 1024×600 panel, Ferris Sweep keyboard, Pico-2-owned audio). The Batch-8 feature synthesis (docs/influences/inspiration/{line,strudel,cmus,upiano,waves,asak,valvefm}.md, docs/influences/effect/cava.md) still stands and is folded in below, joined by 4trk (typed-track architecture + per-step parameter model + the aesthetic north star) and x0xb0x (control-surface lineage, DIY posture, MIDI-as-birthright).

The KN-90 shares the KN-86’s software platform — nOSh/libnosh, the KEC Lisp VM (ADR-0001, ADR-0004), the native framebuffer renderer (ADR-0036), the .kn86 container — but diverges in hardware. The values in §0 below are the KN-90’s own; they do not amend the KN-86 Canonical Hardware Specification, and KN-86 docs must not inherit them. This page is the source of truth for KN-90 hardware values.

0. Platform — the KN-90 hardware deltas

Property	KN-90T value	vs KN-86
Display	Waveshare 7.9” IPS, 1280×400, RGB565 framebuffer (outline ≈ 209 × 77 mm)	Was 1024×600 Elecrow 7”
Cell grid	160×50 at 1× (1280/8 × 400/8). Row 0 = status/transport chrome, Row 49 = action chrome, Rows 1–48 usable. Half-block canvas 160×100 (usable 160×96)	Was 128×75 / 73 usable — the wide-short grid is the fiction’s landscape sequencer timeline, realized
Renderer prerequisite	nOSh geometry parameterization: RENDER_WIDTH/HEIGHT + the cell_api grid become an init-time DisplayProfile (buffers sized to a compile-time ceiling, no malloc). Carts/programs already query (cell-cols) / (cell-rows-usable) — no payload changes	The one runtime work item KN-90 forces; KN-86 is unaffected (its profile is 1024×600)
Case	Waterproof hard case w/ pick & pluck foam, interior 9.2 × 6.5 × 2.7 in (234 × 165 × 69 mm); unmodified shell + 3D-printed inset panel, KN-86 build pattern. Interior ≈ the x0xb0x mainboard footprint (237 × 180 mm)	Smaller sibling of the Pelican 1170 (268 × 153 × 80)
Input	16 step buttons (12 mm illuminated tacts, ≤14.6 mm pitch — MX/Choc do not fit 16-across in 234 mm) + 4 push rotary encoders + transport cluster (PLAY / STOP / REC / FUNC). No keyboard	Replaces the Ferris Sweep (ADR-0031); no KB2040s, no QMK
Primary processor	Raspberry Pi Zero 2 W	Same
Coprocessor	Pi Pico 2 (RP2350) — repurposed as the control-surface processor: button/encoder matrix scan, aux OLED driver, MIDI in/out UART. Reports input events up the existing Pi↔Pico wire protocol (direction inverted vs ADR-0017)	Was the realtime audio coprocessor; audio moves to the Pi (§2). One MCU total
Audio codec	WM8960 (same part as KN-86 / ADR-0054), now used both directions: DAC + speaker/headphone amps out, mic-preamp ADC in. I2S wires to the Pi, not the Pico	KN-86 uses only the output half
Audio inputs	Internal electret capsule + 3.5 mm mic/line-in jack (separate WM8960 input pins — both coexist)	New; KN-86 has no capture path
Audio outputs	Internal speaker (fiction targets 40 mm + passive radiator; driver finalized at sourcing) + 3.5 mm line-out/headphone	Per fiction
MIDI	TRS-A 3.5 mm IN (opto-isolated) + OUT, UART @ 31.25 kbaud on the Pico 2	New; x0xb0x lineage
Aux display	SSD1322 256×64 OLED (same part + driver as CIPHER-LINE), role = PARAM-LINE (§4)	Role change, not part change
Battery	Open. KN-86’s UPS 3S + 3×18650 is too much brick for a 69 mm-deep case; flat LiPo or 2×18650 + smaller PSU board under evaluation	Diverges from ADR-0038

1. The sequencer language IS KEC Lisp (headline — unchanged)

The Toneline does not ship a bespoke sequencer DSL alongside a separate scripting language. There is one language: KEC Lisp, the same VM the Deckline already runs. The fiction’s framing — a song is a list of patterns, a pattern is a list of sequences, a sequence is a list of notes, LAMBDA defines a reusable phrase — is the literal runtime data model:

• A phrase is a list.
• A song is a list of lists.
• LAMBDA (in the Toneline fiction, and on the KEC keycap legends) defines a reusable phrase exactly as it defines any other function.
• The transform verbs are the standard list library — reverse, rotate, shuffle, append, repeat — operating on the phrase-as-data.

The reference is line (pd3v): a CLI live-coding MIDI sequencer that parses a terse text grammar into a nested note tree (phrase → parts → notes) and schedules it. line already proves the boundary KN-86 committed to in ADR-0001/0004 — an embedded language VM owns parsing and structure; the host C runtime owns scheduling and I/O. KN-90 takes the further step line stops short of: the intermediate tree is not hidden behind a private grammar — it is exposed directly as an s-expression.

The larger prior art is strudel (Roos & McLean), the browser port of TidalCycles and the shipping, performed proof of this exact thesis. Where line is the terse entry grammar, Strudel supplies the composition algebra: a pattern is a pure function from a cycle-span to its events, and the transform verbs this section lists as “the standard list library” (reverse, rotate, shuffle, append, repeat, plus every, jux, off, euclid, degrade) are a complete, live-performable language once phrases are first-class values. That is the Toneline’s model, arrived at independently and validated in the wild. Two caveats carried in the entry: Strudel is AGPLv3 with separately-licensed samples, so this is a paradigm reference (design only, never source or sound banks); and its mini-notation string DSL is optional sugar KEC Lisp does not need, since nested lists already are the syntax ((fast 2 (euclid 3 8 'bd))). line and Strudel together bracket the design: entry grammar from one, combinator vocabulary from the other, one s-expression phrase underneath both.

Grammar for the terse text-entry mode (keyboard-present contexts — the desktop emulator, or a USB keyboard on the deck; the KN-90 control surface itself carries no keyboard):

Element	Syntax	Meaning
Note	45 / a3 as3 b3 c4	space-separated note tokens (MIDI number or a/as/b/c+octave), quarter-note default
Subdivision	leading . — 45 .34 35.	a leading . halves a note’s duration (subdivides it)
Chord	(c3 e3 g3)	parenthesized note group plays simultaneously
Arpeggio	(c3 e3 g3) g5 e6	bare notes after a chord = arpeggio
Velocity	d3~.5	~amp suffix sets per-note/per-chord velocity 0.0–1.0
Rest	-	a silent note

The line → KEC Lisp mapping (the crux):

line (terse)	KEC Lisp (structural)
(c3 e3 g3) g5 e6	(seq (chord c3 e3 g3) g5 e6)
45 .34 35.	(seq 45 (div 34) (div 35)) — .x = subdivide
d3~.5	(amp 0.5 d3)
r (reverse)	(reverse phrase)
*4 (concat 4×)	(repeat 4 phrase)
s (shuffle)	(shuffle phrase)
rl / rr (rotate)	(rotate ±n phrase)

Three front-ends, one representation. The 2026-07-04 control-surface direction (§4) replaces the Sweep-keyboard assumption, so the phrase data structure now has three views instead of two:

1. The control surface (primary, on-device). Every physical gesture is a list edit: toggling a step inserts/removes a note in the phrase, a p-lock (§4) wraps a note in a modifier form, keys-mode play appends notes live. The operator is editing s-expressions without ever seeing a parenthesis.
2. The terse line-style prompt (keyboard contexts: desktop emulator, plugged USB keyboard) for speed typing.
3. nEmacs structural editing (ADR-0008) of the same phrase as a raw s-expression — the drill-down for operators who want to see the list. A performer who learns the surface has, without noticing, learned to program the deck.

Notes-vs-control mode: line’s n/cc toggle maps to the Toneline distinguishing note phrases (drive the FM/sample voices) from control phrases (sweep an FM operator’s envelope, modulate tempo, automate a parameter) — same phrase engine, two phrase semantics. With physical encoders, control phrases are naturally recorded: turn an encoder while the sequencer runs and the movement lands in a control phrase (knob-automation capture, the groovebox way).

2. Audio architecture — the Pi owns synthesis and sampling

The KN-86 arrangement (Pico 2 synthesizes → I2S → codec, Pi sends register writes per ADR-0017) inverts on the KN-90, because sampling is a memory problem and the Pico loses that fight instantly (520 KB of SRAM vs the Pi’s 512 MB; streaming PCM down the 1 Mbps UART dies at 705 kbps for mono 16-bit/44.1 kHz before stereo or capture even enter the room).

• The Pi renders the full mix in C — FM voices + PCM sample playback — through the mix seam the runtime already has (nosh_audio_render_samples; the desktop emulator already proves this exact model). The FM engine is a software YM2612 (a Nuked-OPN2-class core is the reference-quality candidate), honoring the fiction’s six FM voices + PCM channel. The PCM sample engine is the one genuinely new engineering surface — no runtime PCM path exists today.
• Pi I2S ↔ WM8960, both directions. Playback out through the codec’s DAC/amps; capture in through its mic-preamp ADC on the same bus.
• Musical timing lives on the audio clock. The sequencer advances by counting samples inside the audio callback — sample-accurate, immune to UI jitter. The UI observes the playhead; it never drives it. (nOSh’s event-driven/20 fps redraw loop is fine for the screens; it is not the tempo source.)
• Latency budget: MIDI in → Pico → UART → Pi → next audio buffer ≈ 6–12 ms at 256-sample buffers — groovebox-acceptable.
• The Pico 2 becomes the control-surface processor: button/encoder matrix scan, PARAM-LINE OLED, MIDI I/O. Input events ride the existing Pi↔Pico wire protocol with the direction inverted; the coprocessor protocol grows a KN-90 profile.

3. Typed tracks (4TRK)

4trk’s track architecture — 8 drum channels + 3 flexible tracks, each flex track configurable as a synth voice or sample player — is the cleanest answer to “how do FM voices and sampled audio coexist in one pattern”:

• Drum tracks — one-shot voices (FM percussion patches or short samples), step-programmed.
• Flex tracks — each assignable as an FM voice (melodic, keys-mode playable) or a sampled voice (a captured take from §5, pitched/sliced).
• Per-step parameter locks on every track — pitch, velocity, probability, roll/ratchet, flam, pan — 4TRK’s per-step model, entered physically via hold-step + encoder (§4).

Exact track counts are a tuning decision for the audio-engine bring-up, not a spec commitment here.

4. Control surface & PARAM-LINE

┌───────────────── 1280×400 · 160×50 grid ─────────────────┐
│ Row 0: 128BPM  BAR 03:2  ▶  PAT:A4  TRK:FM2    transport │
│ Rows 1–48: timeline / lanes / piano strip / waveform     │
│ Row 49: contextual action bar                            │
└──────────────────────────────────────────────────────────┘
   [PARAM-LINE OLED 256×64:  CUTOFF  ▓▓▓▓▓░░░  72%  BNK2 ]
   (E1)    (E2)    (E3)    (E4)     [PLAY][STOP][REC][FUNC]
  [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16]

• 16 step buttons, tri-modal — the x0xb0x-lineage row, physically aligned 1:1 under the on-screen timeline columns:
  1. Step mode — toggle steps on/off in the current track.
  2. Hold + encoder = per-step parameter lock — hold a step, turn an encoder, and that step gets its own pitch/velocity/probability/etc. (4TRK’s per-step model made physical; the Elektron move.)
  3. Keys mode (FUNC-toggled) — the 16 buttons become a playable scale keyboard (chromatic / pentatonic / major, per the fiction’s numpad-pitch scheme), with upiano’s piano-strip widget on the main display showing the active scale (in-key notes by fill density, sounding note inverted). Encoder selects octave/scale. The buttons deliver real press/release, so live polyphonic play works.
• 4 push rotary encoders, bank-switched. The physical realization of the widget kit’s slider + dial idioms (§7). Push = select/confirm; turn = value.
• PARAM-LINE (the aux OLED, same SSD1322 part + driver as CIPHER-LINE): shows the name + value + bar of whatever you’re touching — last-turned encoder, held step’s p-lock, active bank/page — plus a contextual hint row. The classic groovebox “eyes stay on your hands” display. No CIPHER voice on the KN-90.
• Transport cluster: PLAY / STOP / REC / FUNC. FUNC is the single modifier layer (mode toggles, page left/right for >16-step patterns via FUNC+step).
• Mode-selector splash (asak) as the front door: boot into SEQ / REC / VOICES / SYS; BACK always returns home. With no keyboard, mode structure must be shallow and physical — the splash is the navigation spine, not decoration.

5. Sampling & recording (asak) — core, not deferred

The record path is a launch feature (the point of the mic + line-in hardware), per asak’s loop:

arm → live-monitor waveform during capture (input level/shape + elapsed take timeline on the main display) → save → the take lands in the voice library on the cartridge SD, immediately assignable to a flex track (§3) and placeable in phrases. Input source = internal electret or the 3.5 mm mic/line jack (WM8960 ADC either way). Take naming on-device is encoder-driven character entry — keep it minimal; the library UI carries the weight.

6. Single-color audio visualization (cava)

Reference: cava — the canonical terminal spectrum visualizer.

• Eighth-block ramp ▁▂▃▄▅▆▇█ (U+2581–2588) gives 8× sub-cell vertical resolution: a bar’s top cell is drawn with the partial eighth-block matching its fractional height, so an N-row spectrum reads as if it had 8N levels. Color is fully separable — the information channel is height + density only. Encode the eight ramp glyphs as guaranteed entries in the KN-86 Code Page bitmap font (pixel-exact on the single-phosphor grid; no Unicode-terminal dependency — cava’s own cava.psf precedent).
• cavacore DSP/render split: build the visualizer as a pure DSP core (audio samples → bar magnitudes) cleanly separated from the grid renderer (magnitudes → glyph rows). One core feeds two thin renderers: the main-grid spectrum (rows 1–48) and a compact PARAM-LINE level meter.
• Expose the band array as a NoshAPI primitive (cava’s “raw mode” seam — the visualizer’s output is just an array of bar heights), so a payload draws its own visualizer in KEC Lisp without touching the DSP.
• Input is the Pi-rendered FM/PCM mix, tapped at the nosh_audio_render_samples seam (§2) — not a host-audio loopback.
• Animation profile: peak-hold with gravity fall-off + light temporal smoothing + auto-sensitivity (cava’s gravity-decay model, so bars decay naturally instead of snapping).

7. UI component kit (single-color)

Four reusable single-color widgets, drawn in the cart-usable rows (1–48); the encoders are their physical mirror:

• Piano strip (upiano) — the keys-mode companion (§4): a horizontal keyboard band showing the active scale and the sounding note. White keys = phosphor-outlined cells on black; black keys = filled phosphor blocks (██) above; the sounding note inverts; in-scale vs out-of-scale differ by fill density, not hue.
• Linear slider (upiano) — VOL ├────●───────┤, position-only, carried entirely by character + position. The on-screen view of a bank’s continuous parameters (operator levels, envelope rates, feedback, volume/reverb).
• Rotary dial (valveFM) — ◄ ──────●──── ► or a radial box-drawing sweep, value = marker position. The on-screen twin of a physical encoder: tempo, FM operator ratio, filter cutoff, arrangement scrub.
• Waveform-with-playhead (asak) — a centered band of block characters (▁▂▃▄▅▆▇█ above/below a center line) whose height tracks amplitude over time, with the playhead a single inverted column. The time-domain view (take review/editing, sample slicing) complementing cava’s frequency-domain spectrum (live monitoring). A complete Toneline audio UI uses both.

8. Shell scaffolding (cmus + waves)

The UX discipline wrapped around the phrase engine, from cmus and waves, re-based on the button surface:

• Mode-first view switching — cmus’s “one key, one surface” discipline lands on the splash modes + FUNC-layer jumps (FUNC + step 1–4 = SEQ / REC / VOICES / SYS) instead of a digit cluster.
• One-line compact transport bar — tempo (BPM), current bar/beat, play/stop state, current pattern/track, mute — packed into the firmware-owned Row 0 by position + fixed-width formatting (128BPM 03:2 ▶ PAT:A4 TRK:FM2), mirrored to the PARAM-LINE status when nothing is being edited.
• Library-vs-queue separation — the durable phrase/patch/take library lives on the cartridge SD; the transient performance queue (what plays next) is built and drained live. The catalog is not the playlist.
• Persistent toggle-able queue panel (waves p) + undo/redo on list edits — keep the performance queue docked beside the sequencer so the operator builds the live set without losing the phrase being edited; undo/redo is first-class because an arrangement IS a list and every reorder/drop/swap is a list edit.
• Song → Pattern → Phrase → Sequence drill-down — waves’s Artist→Album→Track browser tree, re-pointed at the Toneline’s music nesting. (Indexed/fuzzy search is the natural scaling layer once a cartridge holds many phrases/takes.)

9. MIDI & LINK

Physical MIDI is the LINK port, realized: TRS-A 3.5 mm IN (opto-isolated) + OUT on the Pico 2’s UART (§0, §2).

• MIDI clock sync delivers the fiction’s two-Toneline jam — one deck masters the clock, the other follows; loop updates quantize to bar boundaries.
• External gear comes free: sequence a hardware synth from the Toneline, or play the Toneline’s voices from a MIDI keyboard.
• line’s Ableton-Link-style shared-beat model is deferred to a possible host-DAW bridge; MIDI clock covers the on-device story.

Scope: v0.1 vs deferred

v0.1	Deferred
KEC Lisp phrase representation (phrase = list; song = list-of-lists; LAMBDA phrases; reverse/rotate/shuffle/append/repeat transforms)	Terse line-style prompt on-device (keyboard-present contexts only in v0.1: emulator / USB keyboard)
nOSh DisplayProfile geometry parameterization (the runtime prerequisite)	nEmacs structural-edit front-end for phrases (ADR-0008 dependency)
Typed tracks (drum + flex) with per-step p-locks	Indexed/fuzzy phrase + patch + take search at cartridge scale
Tri-modal step buttons, bank-switched encoders, PARAM-LINE, mode splash	Persistent toggle-able queue panel + undo/redo on arrangement edits
Record → monitor → save sampling loop (mic + line-in capture into the voice library)	Ableton-Link-style DAW bridge
MIDI in/out hardware + MIDI clock sync	—
cava-style eighth-block spectrum + cavacore DSP/render split	Cart-facing NoshAPI spectrum-band primitive
Row 0 transport bar, library/queue separation, drill-down browser	—
Notes-vs-control phrase modes (incl. encoder-automation capture)	—
Piano strip, slider, dial, waveform-with-playhead widgets	—

Fiction → buildable mapping

Flagging the deltas rather than forking the fiction spec:

• Display: sideways Sharp 240×128 LCD → Waveshare 7.9” 1280×400 (§0). The landscape horizontal-timeline intent survives intact — 160 columns is the widest canvas in the Kinoshita line.
• Input: 16 function keys + numpad → 16 step buttons + 4 encoders + transport. The numpad’s digit-to-pitch scheme survives as keys mode (§4).
• Audio: the YM2612 FM chip → software YM2612 emulation on the Pi (§2), plus the sampling path the fiction never had (the 1990 device could only play; the reconstruction records).
• LINK: the serial-cable LINK port → MIDI clock over TRS-A jacks (§9).

Source inspiration

Synthesized from the Batch-8 audio TUI entries plus two hardware/aesthetic lineage references:

• line — CLI live-coding MIDI sequencer; the primary sequencer-language reference (phrase grammar → KEC Lisp s-expression mapping; phrase queue + persistence; shared-beat sync; notes-vs-CC mode).
• 4trk — compact retro tracker/groovebox workstation; the aesthetic north star and the typed-track + per-step-parameter architecture reference.
• x0xb0x — TB-303 clone DIY kit; the control-surface lineage (step-button row, MIDI-as-birthright), the open-hardware posture, and the case-scale coincidence (§0).
• cava — terminal spectrum visualizer; the single-color audio-visualization reference (eighth-block ramp, cavacore DSP/render split, band-array FFI seam).
• cmus — console music player; view-switching discipline, one-line transport bar, library-vs-queue separation.
• upiano — playable terminal piano; the piano-strip and linear-slider widgets, and the pitch-surface model behind keys mode.
• waves — TUI music player; persistent queue panel, undo/redo on list edits, Song→Pattern→Phrase→Sequence drill-down.
• asak — audio recorder/player TUI; mode-selector splash, waveform-with-playhead, the record→monitor→save workflow.
• valveFM — vintage FM tuner TUI; the rotary dial idiom (now physically realized by the encoders).