GitHub & source setup

Everything SoundChex ships starts at github.com/tripsittr/SoundChex — the source, the compiled installers, the issue tracker and the changelog. This page explains how the pieces fit and how to run from source.

The repository, in one minute

Where	What
Releases	Compiled installers — the `.dmg`s for macOS and, when they ship, the `.exe`s for Windows — for both SoundChex (the client) and SoundChex Server. Each release carries its changelog. This is what the download page links to.
Issues	The support channel. Bugs, questions and feature requests all go here — there is no separate forum.
The code	AGPLv3-licensed. The server (Laravel/PHP), the web interface, and the Tauri shells all live in the one repository.
`docs/`	The developer-facing docs, kept next to the code they describe.

Hear about new versions: on the repository page, Watch → Custom → Releases. GitHub then emails you when a release lands — the served interface updates itself, so this mostly matters for the server and the app shells.

Installers or source?

Installers — right for the client apps, and for a host machine where a .dmg / .exe is the comfortable route.
Source — right for Linux hosts (no installer yet), for staying on the newest code, and for contributing. It's a normal Laravel app; nothing exotic.

Running from source

Clone and follow the guide for your OS — each covers its own toolchain and traps:

git clone https://github.com/tripsittr/SoundChex.git
cd SoundChex

Install on macOS
Install on Windows — read this one even if you're comfortable; two of its steps fail silently when skipped
Install on Linux

Updating a source install

git pull
composer install
npm install
php artisan migrate
npm run build

Then restart the background workers so they run the new code. Because the interface is served, every connected device picks up the update on its next page load — the apps themselves rarely need reinstalling.

Migrations are part of every update. git pull without php artisan migrate is the classic source-install mistake — new code against an old schema fails in ways that don't name the cause.

Building the installers yourself

Every .dmg and .exe we publish can be reproduced from the repo — that's the point of the code being public:

npm run build              # web assets first, always
npm run tauri build        # the client app for the OS you're on
npm run build:server       # the SoundChex Server app

Builds are per-platform — a Mac produces the .dmg, a Windows machine the .exe; no machine cross-builds the other's installer. Platform specifics live in the per-OS install pages, including the macOS DMG-bundling recovery in Install on macOS.

Contributing

Issues first — even for a fix you intend to write, so the work is visible. Run the tests (php artisan test, npx vitest run) before opening a PR, and expect every change to reach main through a pull request with a changelog entry. The repository's AGENTS.md describes the conventions in full.