Skip to content
RESONON

How Preferences Are Applied

Preferences are a file, and a file can ask for things this machine cannot give. This page explains how resonon applies it so that a bad line cannot cost you a session — at startup, or while one is playing.

A key nobody can honour costs only itself

Section titled “A key nobody can honour costs only itself”

A rate this interface cannot run, a block size out of range, a folder that does not exist: each is named, dropped, and the rest of the file is applied. A rig with none of it right still comes up and runs.

Warning: /Users/you/.resonon/preferences.toml asks for audio this machine cannot give:
  `[audio] sample_rate` 192000 — the device does not run at that rate; it does 44100, 48000, 96000
Everything else in the file is applied.

A device you named is a device you get, or none

Section titled “A device you named is a device you get, or none”

The one key that is never traded for something else is the hardware. Name an interface that is not connected and resonon waits for it: nothing plays, the message says which device it is waiting for, and no other device is opened in its place.

Warning: /Users/you/.resonon/preferences.toml asks for audio this machine cannot give:
  `[audio] output` "Scarlett 2i2" — is not connected, so it is what this session is waiting for
  rather than something else to open in its place. Connect it and press play; this machine has:
  MacBook Pro Speakers
Everything else in the file is applied.

Plug it in and press play: PLAY is what opens the device, so there is nothing to restart and nothing to edit. The same holds for an interface unplugged mid-session — playback stops, resonon says so, and play picks it up again when it is back.

This is the one place resonon refuses to be helpful on your behalf. Silently moving a session onto the laptop speakers is how a monitored microphone ends up in a feedback loop, and a rig you pinned to its converters is a rig that should stay there. [audio] input follows the same rule in its own half: a microphone that is not connected leaves capture closed rather than opening the built-in one, and playback is untouched.

Preferences are never rewritten for you. An interface you unplug keeps its name in the file, so plugging it back in is all it takes.

Block size and rate are reported, not assumed

Section titled “Block size and rate are reported, not assumed”

A backend is free to ignore a fixed block size — WASAPI in shared mode always does, CoreAudio may clamp — and a rig that believes it is running at 128 frames while the device hands it 512 is a rig whose owner is debugging the wrong thing. So resonon reports the size the device settled on.

sample_rate is the whole session’s, not the output’s alone. Left unset, resonon picks a rate the devices you named for input and output can both run at — which is how a pair like AirPods, whose microphone only does 24 kHz, works without being configured. Set it and your rate stands: an input that cannot join is refused rather than allowed to move the session.

MIDI ports are entries, not a map

Section titled “MIDI ports are entries, not a map”

[[midi.outputs]] and [[midi.inputs]] are arrays of tables rather than an alias = "port" map, for two reasons: the order is meaningful, and optional is a fact about one entry rather than about the table — as is how an output’s device is driven, its trims and whether it takes clock.

An absent device keeps its alias, so a piece pointed at it stays valid and says what is missing. Nothing notices a device being plugged in or pulled out on its own yet — reload_preferences() is the gesture that looks again. Moving an alias to another port and reloading moves it there even when the new one is not plugged in: the file wins, and the missing device is reported as missing rather than the old one being kept.

A port declared here and not plugged in stays on resonon setup’s list and stays selected: unplugging a synth is not a decision to stop using it.

A change waits to be applied

Section titled “A change waits to be applied”

Editing the file changes nothing on its own. Nothing watches it, deliberately: a stray editor save should not be able to reopen your audio device under a take. reload_preferences() is the gesture that applies it — the same act as clicking in Live’s Preferences dialog, for a file that changed underneath you.

Applying is built so that it cannot hurt a session that is playing:

  • It applies only differences, so calling it on an unchanged file costs nothing and makes no gap in the sound.
  • A file that will not parse changes nothing. The whole file is read before anything is touched, so it cannot half-apply.
  • Past that, a key nobody can honour costs only itself. A missing MIDI port does not cost you your buffer size.
  • A take is left alone. While one is recording, the [audio] section is not touched: the recording offset trims the head of the take, and a new rate would stitch two devices into one.

It covers every setting in the file, the folder lists included, for the same reason: a search list that moved because a file was saved could move mid-take.

Section titled “Related”