What the other two applications keep

Every setting on this page belongs to the standalone player. The other two applications keep their own choices in their own files, on the same rule: a setting is a key in a file you can edit, and a menu or a panel is an editor of that file.

The studio persists through a settings.json beside its own data, written by studio/electron/settings.ts. Nothing it shows is kept in browser storage — localStorage, sessionStorage and indexedDB all keep a choice where no file can be edited and no other process can read it, and scripts/check-settings-have-files.mjs is what holds that to being a property rather than a habit.

Key	Values	Default	What it does
playerPath	a path	none	An explicit player binary, tried after the bundled one and before PATH
playerMode	windowed, windowless	windowed	Which sink the player is spawned with; read at spawn
ui.reducedMotion	true, false	false	Stops the studio’s transitions: panels, tabs and dialogs appear at once. Applied the moment the Settings view writes it. The system’s own reduced-motion preference does the same whatever this says
render.ffmpegPath	a path	ffmpeg on PATH	The ffmpeg a clip render transcodes the track with and encodes the MP4 with. Read at each render
render.outputDir	a directory	the user’s Videos directory	Where a clip render’s MP4 is suggested. Read at each render
render.diffusion.python	a path	none	The interpreter the diffusion sidecar runs under, such as a venv’s python with torch installed. While it is absent the Render view’s neural switch stays off
render.diffusion.script	a path	none	tools/sd-filter/sd_filter.py in a source checkout. While it is absent the neural switch stays off
judging.sourceDir	a directory	none	The preset directory a judging session draws its sets from, typically a checkout’s presets/. Read at each session; while it is absent the Judge view asks for one

The studio’s Settings view shows playerPath and edits every other key. A settings.json written by hand before the first launch is read the same way.

The foobar2000 component has no settings and no file, and the one thing it stores host-side is not one. g_cfg_preset is a cfg_string holding the name of the preset that was last on screen, so a session reopens on the look it closed with. That is resume state, not a setting: nothing about it is chosen, an empty value or a name whose file is gone simply means “whatever the roster opens on”, and forgetting it costs a user nothing but the preset they were watching. The same gate holds every cfg_* declaration in that shim to being named here — which is the only way resume state can be told apart from a setting nobody gave a file.

The day the component grows a real setting, it belongs in config.toml beside the player’s, not in foobar’s own store.