In parametric, structurally stable design domains, a control surface composed of spatially fixed, multi-modal physical inputs paired with a dedicated legend display can carry human intent into 3d modeling workflows more richly and memorably than generic mouse-and-keyboard menu systems.
Why this matters
The argument is not that mouse/keyboard should disappear.
It is that in expert, high-intent, parameter-dense workflows, today’s defaults are often historical/economic defaults rather than interaction-optimal defaults.
Evidence and method: thesis and framing
- Q (AI): “In your own words, what is the central argument?”
[Shaw]: “The thrust of this work is to provide a more human method of input into a computer—something more physically memorable that can function with muscle memory, work in conjunction with physical movement and the screen, be more expressive, and meet the channel of getting human ideas into a computer model as intent-bearing as possible.”
- Q (AI): “Is this superior or complementary to conventional input?”
[Shaw]: “Not just rotary encoders, but physical encoders more broadly. There are sliders that have been modified in conjunction with the rotary encoders. The keyboard is mainly a text device, and that can be supplanted by voice input. I do not find the mouse practical. The touchscreen functions as a display and as flexible visual feedback, so it still has validity. In my application, the control system is meant to be used in conjunction with a touchscreen.”
- Q (AI): “Does this thesis capture your argument?”
[Shaw]: “Yes—something like: a control surface dependent upon physical interaction with rotary encoders, sliders, spaceball manipulators, and/or trackballs provides a more intent-bearing, physically memorable, and expressively rich channel for human-to-computer interaction, more so than conventional mouse and keyboard paradigms.”
- Distilled restatement (published thesis line) preserves this lock while bounding scope to parametric/structurally stable domains.
Constructed interaction model
The model combines:
- Stable physical layer A 16-control (
4x4) physical surface that remains spatially fixed.
-
Dynamic semantic layer A touchscreen legend defining the current room/page and active mappings with a 1:1 scale active legend for the physical dials.
-
Bidirectional visual signaling Active controls illuminate and color-match to the legend; inactive controls dim, both on screen and the physical device.
This creates a practical memory architecture: hand-memory remains stable while semantic context changes page-by-page.
Evidence and method: memory-palace mechanism
- Q (AI): “How do you keep the mapping stable enough that the palace does not collapse?”
[Shaw]: “In my setup, the 16-dial box is like an extension of my hand. I use my hand in many different rooms—to open a door, to grasp a mixer, to handle a saw, to touch a face. The hand is a common interface mapped to different situations. In the same way, the physical control surface is constant, and the different rooms are represented on the touchscreen. The touchscreen pages are the rooms of my system. One set of functions lives on one page, along with a screen legend that matches the physical size and layout of the dial box. The legend shows where each function maps to each dial. So the hardware remains a stable hand, and the touchscreen defines the room I am in.”
-
Specialist use statement (Shaw): pro control surfaces are for trained operators; cognitive economy comes from training, not from one-button simplification.
-
Training ramp (Shaw): active dials light up, inactive controls gray out; function set can be gradually unveiled.
Control mechanics explored (what is physically novel)
-
Rotary knobs are physically modified into off-center bearing-mounted jog pads.
-
Fingertip spiralling is continuous, unlike the angle limited “grip and twist” of dials
-
Input is interpreted as signed rate-of-change, not just absolute position.
-
Precision ranges from hundreths of a unit per revolution to 10’s of units, depending on velocity of spin.
-
Spaceball remains unmodified as a high-value 3D complement.
This stack supports both coarse navigation and fine incremental adjustment while keeping eyes on geometry.
Evidence and method: mechanics
-
Encoder modification [Shaw]: “I physically modified the knobs so that each became an off-center rotary pad mounted on a bearing. The fingertip rests on this pad and stays in contact; the pad spins on the bearing rather than the skin sliding over plastic. The pad rotates around the central axis at different speeds, like a scaled-down jog wheel on a video editing system. Each knob becomes a tiny velocity-sensitive jog wheel.”
-
Rate semantics [Shaw]: “In software, I remap these so they express rate of change: positive and negative rates within the MIDI spec, with 64 steps of clockwise velocity and 64 steps of counterclockwise velocity.”
-
Slider banking solution [Shaw]: “Traditional banking has a problem: when you switch banks, the physical slider position no longer matches the values in the new bank unless you use motorized faders … My solution was mechanically self-centering sliders: each slider springs to the midline, representing zero. … This solves the bank-position problem, because bank or page changes do not require synchronization of absolute positions; the slider is always at zero unless being deflected to express change.”
-
Spaceball role [Shaw]: “The spaceball is simply a non-mouse component that already works very well. … Grabbing a spaceball and pushing, pulling, spinning, turning, and twisting feels very close to directly manipulating the object on screen. I would describe it as a near-perfect experience.”
-
Control intuition [Shaw]: “When I am modeling a parametric object, I can keep my eyes on the screen and watch the model change while my fingertip rests on the jog wheel pad. … The rate of change I see on the screen, whether I need to move quickly to a new region or adjust something very finely, becomes completely intuitive.”
Domain fit
Best-fit domains are parametric, repetitive, and structurally stable:
-
helmet workflows,
-
collaborative form development with multiple operators.
Poor-fit domains are explicitly acknowledged:
-
fast-twitch gaming,
-
ad hoc vector illustration with rapidly shifting tool semantics.
Evidence and method: applicability boundaries
-
Best-fit examples (Shaw):
-
Eyeglasses [Shaw]: “A very lightweight application I can imagine is designing eyeglasses: parameters like spacing, ovalness, angularity, frame sides, tapers, and tilt could all be mapped into a simple, multi-page interface.”
-
Collaborative car model [Shaw]: “A more complex example would be car design … with several operators working on a shared parametric model at the same time. One person might control overall volume, another wheel wells and body tapers, another the belt line height.”
-
Additional direction [Shaw]: “I also think control of weights in AI structures could benefit … systems like ComfyUI could map nicely to a physical shader surface.”
-
Non-fit examples (Shaw):
-
Gaming [Shaw]: “There are at least two scenarios where this would not be applicable. One is game playing … movement is immediate, directional, and not parameter-based. My control surface would not be appropriate.”
-
Vector drawing [Shaw]: “Another is a vector drawing program where the types of input keep changing on screen … There would be no time to learn or benefit from a stable physical system.”
-
Scope statement: this is intentionally specialist and domain-specific, not a universal replacement for mouse-based interaction.
Discussion points
-
What is the practical upper bound of simultaneously visible physical controls before mapping confusion dominates?
-
How should room/page layouts be designed so that training transfers across projects?
-
Which CAD/parametric environments could adopt rate-based physical input with minimal integration cost?
-
Where should these systems remain intentionally specialist rather than generalized?
Document creation method notes
By Shaw Kaake — Sapporo, Hokkaido, Japan — Session date: 2026-05-04
The intent of this structure is to communicate and demonstrate the provenance of the concepts contained within. It grew out of a desire to track my own thoughts (and guard against glazing) through LLM editing and to be challenged, rather than coddled, essentially a treadmill, not a Segway. This version follows a formal structure and, in this Core77-specific format, takes full advantage of available formatting options.
This document format is the product of orchestrated efforts from Cursor, Claude Code, and Perplexity. A workflow built by the author to preserve his voice, avoid meaning drift, and avoid insertion of unsupported information. The role of the system is documentary and editorial, with each step governed by strict rules of conduct. There is an evolving heatmap function in richer formats to show the machine contributed edits and original spoken content in a more visual manner.
The working title across the engines is: Conversation Spec v0.6.
The basis is an interview: questions are proposed and evolved throughout the conversation by the LLM and answered by voice dictation from the author. Five interview methods are available for selection. Answers and assumptions are then challenged through staged options, including: no proposal, steelman proposal, explicit edit options, and confirmation at each stage.
The interview is then distilled into a thesis and confirmed point by point. A distillation document is produced, and then formatted into a Discourse-style post draft, with supporting interview evidence available on expansion of indicated summaries.