Bindings
A binding maps a trigger to a workflow. Your button bindings are workflows too — with a builder in front of them. Your Mac owns the list.
A workflow says what happens. A binding says when it happens, and where it applies. A binding maps a trigger to a workflow, and nothing more.
They are separate on purpose. One workflow can be bound many times — the same Dictation you use on a button can also sit on a keyboard shortcut — and each binding is switched on and off by itself.
What a binding holds
A trigger, a workflow, and a scope.
The trigger is the event: a device button and gesture, a button drawn on a glance, a global hotkey on your Mac, an always-listening microphone, or a manual run.
The workflow is the logic — the reference to what runs. Many bindings can point at the same one.
The scope narrows it: which virtual device, which physical device, which surface, which button, which gesture. A binding that takes a button slot on the device needs the surface, the button and the gesture together — the projector places a slot only when it has all three.
Your button bindings are workflows
Here is the part that surprises people: when you bind a button, you are building a workflow. You just do it through a quick picker instead of the full editor.
Open the picker on a gesture and it asks what the button should do — type a shortcut, run an action on the device, or, on a hold, send your voice somewhere. Whatever you choose, the companion assembles a small workflow behind that button on the spot. You never open the editor, but the thing you made is a workflow all the same. Or you skip the builder and point the button at one you already saved.
That difference matters in one place. A saved workflow is shared: every binding aimed at it runs the same steps, and editing it once changes all of them. A workflow the picker builds belongs to that one button, and it is cleared away when you rebind. Either way, the binding is only the input side — which button, which gesture — and the workflow is the logic.
What a button can point at
A button and gesture
One slot you are binding.
- typesKeys on your Mac
Press a shortcut — copy, paste, a hotkey. This one runs on your Mac; the device only sends the press.
- runsAn action on the device
Sleep, volume, an app command. It happens on the device itself.
- sendsYour voice somewhere
On a hold: stream or transcribe your voice to wherever you point it.
- reusesA workflow you saved
Point the button at one you already built. Change it once and every binding that uses it follows.
The buttons you actually have
Your device has physical buttons, and each one answers to its own set of gestures. A binding names one button and one gesture on it. Which buttons you get, and which gestures each one answers to, come with the device — so the companion draws you the real grid for the device in your hand. Below is the one on the 1.8.
The screen is a second input path. A tap on an app's own surface arrives the same way a physical press does, and a swipe that starts at a screen edge is a system gesture the device handles itself.
A glance can carry its own buttons, too. A button placed on a glance — an action — is a trigger like any physical one: a tap on it runs the workflow you bound, and it reports back on the same surfaces, inline in the button by default. The only difference is where the press comes from — the device's screen rather than a hardware key — so the same action rides any board, whatever physical keys it happens to have.
Every button slot on the device, and what is in it
- Acts out of the box
- 1
- Yours to bind
- 4
- Not on this board
- 1
Main
Aux
Notice the hole: aux has no hold on this board. A button offers the gestures its board gives it, and aux here gives a tap and a double. That makes five slots on the 1.8, and one of them already does something. A board with a third button, or with a hold on aux, simply shows you more of them.
Your Mac owns the button map.
Your Mac holds the list of what every button does. The device keeps a copy of that list. You never edit the map on the device — you change it on your Mac, and the device gets the updated copy.
This is why a button can change its meaning without reflashing anything.
How the copy stays in sync
Your Mac's binding list is the single source of truth. The button map each glance stores on the device is derived from it — worked out on the Mac and sent to the device, never authored there. On a fresh companion with no bindings of its own, the flow reverses once: it adopts the map it reads back off the device.
What the device decides by itself
Two things run on the device without asking your Mac.
A gesture with no binding on the current glance falls through to the firmware's default map. On this board that map holds one entry — an aux tap sleeps the device — and every other slot is a no-op until you bind it.
While an app's face is on screen, the app owns the buttons. The press resolves against that app's own surface, and the glance underneath does not also fire.
Not everything reaches the device
A binding takes a slot on the device only if the workflow has something for the device to do.
A workflow that captures audio becomes a real binding on the device, because the device has to start the microphone. A workflow that types keystrokes on your Mac projects nothing: the device emits the press, and your Mac does the rest. So a long binding list on your Mac can map to an empty one on the device.
That split shows up in where a binding fires. On the device, a bound button resolves against the glance you are looking at — the firmware looks the press up in the active glance's table. A keystroke workflow fires from your Mac's router, which matches the button and the gesture that reach it.
While a workflow runs
A binding does not fire and vanish. While its workflow runs, you get a live status back: the companion shows what the run is doing, and a device screen can carry a short label while a hold is live — a quiet "Listening…" through the hold, then nothing once it lands.
Today that status is honest but thin. It tells you a run is live, that it finished, or that it hit an error and why. A finer, step-by-step read — transcribing, then thinking, then speaking — is a direction the design leaves room for, not something you watch phase by phase yet.
What a new device does out of the box
The matrix above is mostly empty, and the empty slot people ask about is push-to-talk.
Sleep is seeded because it is the one action that needs no configuration to succeed. Push-to-talk is not: it needs a speech provider, and a talk button seeded before one exists fires an unconfigured path and reports that voice is unavailable. So the slot is left for you.
Not every destination needs a provider. A workflow that transcribes does — the text has to come from somewhere. A workflow that streams raw audio into the virtual microphone does not, and it can take the hold on its own. See Bind your buttons.