The command line.
The full command tree, the quiet Windows binary, and AutoHotkey scripts that actually toggle.
If you can talk to the API directly, prefer it. The CLI can set things, but it can’t read the GoXLR’s current state back — and for anything that toggles, you need to know the state.
Where the binary is
- Windows:
C:\Program Files\GoXLR Utilityby default.cdthere first. - Linux:
goxlr-clientis on your$PATHif you installed from a package.
The command tree
Run any partial command and it prints its own help, so the CLI is genuinely self-documenting. The top level:
| Command | Covers |
|---|---|
| profiles | Profile settings |
| microphone | EQ, gate, compressor |
| volume | Channel volumes |
| submix | Sub-mix settings |
| bleep-volume | The bleep button level |
| faders | Fader assignment and behaviour |
| cough-button | Cough / mute button |
| router | The routing matrix |
| lighting | Colours, brightness, blink states |
| effects | Effects settings |
| sampler | Sampler banks |
| settings | Utility settings |
Descending a level, goxlr-client profiles gives you device (the general device
profile) and microphone (the mic profile). And goxlr-client profiles device gives you
new, load, load-colours, save and save-as.
Reading a signature
goxlr-client profiles device load <PROFILE_NAME> [PERSIST]
Angle brackets are required, square brackets optional. [PERSIST] takes true or
false. So, in practice:
goxlr-client profiles device load Frosty
--help works at every level. Between them the subcommands cover everything the GUI can set,
with a few corners undocumented.
The quiet binary (Windows)
goxlr-client-quiet takes exactly the same parameters but runs without spawning a Command
Prompt window and prints nothing. That matters more than it sounds: bound to a hotkey during a fullscreen
game, the ordinary binary’s console flash steals focus.
Reading state over HTTP
The daemon’s web server listens on port 14564 by default. Two endpoints are useful from a script:
| Endpoint | Returns |
|---|---|
| http://localhost:14564/api/get-devices | The entire device state as JSON |
| http://localhost:14564/api/path?path=<JSONPATH> | One value, selected by JSON Path |
For example, the name of the currently active profile:
http://localhost:14564/api/path?path=$.mixers..profile_name
AutoHotkey
These target AutoHotkey v2, so scripts open with #Requires AutoHotkey v2.0.
Two keys, two profiles
The simplest useful thing: bind Ctrl+Z and Alt+Z to load a profile each, using the quiet binary so nothing flashes on screen.
#Requires AutoHotkey v2.0 ^z::Run 'goxlr-client-quiet profiles device load Headphones' !z::Run 'goxlr-client-quiet profiles device load Speakers'
Saving before you switch
Wrap the hotkey body in braces to run more than one command — here, saving the current profile before loading the next, so tweaks you made by hand aren’t lost.
#Requires AutoHotkey v2.0
^z::
{
Run 'goxlr-client-quiet profiles device save'
Run 'goxlr-client-quiet profiles device load Headphones'
}
One key that toggles
This is where the CLI alone runs out. To toggle, you have to ask the daemon which profile is loaded,
and that means the HTTP endpoint. Fetch the profile name with a WinHttp request, then pick the other one.
Using InStr on the response text sidesteps needing a JSON parser in AHK at all.
#Requires AutoHotkey v2.0
^z::
{
url := "http://localhost:14564/api/path?path=$.mixers..profile_name"
req := ComObject("WinHttp.WinHttpRequest.5.1")
req.Open("GET", url, true)
req.Send()
req.waitForResponse()
profile := req.ResponseText
Run 'goxlr-client-quiet profiles device save'
if InStr(profile, "Headphones")
Run 'goxlr-client-quiet profiles device load Speakers'
else
Run 'goxlr-client-quiet profiles device load Headphones'
}
Written from the GoXLR Utility project’s own documentation (The CLI and AutoHotkey) and reproduced here in our own words, so you don’t have to leave the site. The project’s originals remain the authority if anything here goes stale.