trackyard

A searchable, tag-based, login-free registry to upload and find .track parts — instrument packs, waves, motifs, tunings, full songs. Live at trackyard.p11c.xyz, part of the game-audio ecosystem.

Uploading

Drop a .track file — no login, no account. Every upload is loaded through game-audio and written back out (parse → Display), which has three effects:

• Invalid files are rejected with the parser's exact error message (line number included).
• Unknown or junk sections are stripped — the stored file is always clean, canonical .track.
• The format is normalized, so files in the registry all look the same regardless of how they were written.

Uploads must also be complete: every instrument used by a note or motif placement, every waveform used by an instrument, and every placed motif must be defined in the file or provided by one of its imports. Incomplete uploads are rejected with a list of what is missing. (If the track has URL imports, this check is deferred to rendering, since the server does not fetch URLs during upload.)

Empty tracks are rejected too: a file that defines no sounds, waves, motifs, tunings, or layers and imports nothing is metadata only, with nothing to share — so description-only uploads do not land in the registry.

You can also select several files at once to upload a group of related tracks together. Each is given its id up front, and bare <name>.track imports or jump targets that name a sibling in the batch are rewritten to that sibling's id — so a suite whose tracks reference each other (a jump loop, say) goes in as a unit, which is impossible one file at a time. A batch is all-or-nothing: if any file is invalid, empty, or a duplicate, none are stored; references matching no sibling, registry track, std:, or URL get a shared fix form.

Uploading requires agreeing that the track is published under CC0 — everything in the registry is free for anyone to use. The upload limit is 1 MB.

Ids & duplicates

An entry's id is a random identifier, assigned once at first upload and fixed for the entry's whole life, even across reuploads — so download, play, and import links never break. It is independent of the content: a track's music is fingerprinted separately, only for duplicate detection.

Duplicate detection compares that content fingerprint (metadata — title, author, description, tags — excluded), stored per entry and updated on every reupload: uploading music that is already in the registry, even under a different title or tags, is flagged and points you to the existing entry instead of creating a second one. That flag only fires on byte-identical canonical content — change a single note, sound, or wave and it uploads as a new entry.

A changed version of a track is published by reuploading the existing entry (which keeps its id, votes, comments, and dependants), not as a fresh upload — see Editing.

Imports

Tracks may import other tracks (@import) under a strict policy. Allowed are exactly:

Anything else — relative or absolute local paths from the uploader's machine — triggers a replacement form: each offending import gets a field (with autocomplete over all registry tracks) to substitute a URL or a registry entry, and the upload proceeds with the rewritten imports.

A @jump target (where interactive music continues when a section ends) is a .track reference too, so it follows the same policy — localized, validated, and counted as a dependency just like an import. A jump that loops the track back to itself (@jump <own-filename>) is recognized and rewritten to the entry's own id automatically, with no fix step.

Bare registry imports and jumps form a graph: each entry page lists its dependencies (the registry tracks it references) and its dependants (the registry tracks that reference it), both as clickable links to those entries.

Tags

Every entry carries two kinds of tags:

• auto tags — derived from content, never assigned by hand: song or part (has playable layers or not), pack (imports other tracks but defines nothing of its own, like a bundle), plus sounds, waves, motifs, tunings for whatever the file defines.
• free tags — chosen by the uploader (nes, lead, boss-theme, …).

The file's own ## Tags section (under # Meta) is the source of truth: tag edits are written back into the stored .track, so a part stays self-describing outside the registry too.

Tags are normalized to lowercase a-z, 0-9 and -; anything else becomes a dash. Boss Theme, boss_theme and boss-theme are the same tag. At most 16 tags of up to 32 characters each.

Editing & ownership

Ownership is a visitor cookie — still no login. The uploader (and the admin) can edit an entry's metadata: title, author, description, and tags.

Uploading redirects straight to the edit page, pre-filled from the file's own metadata. The tag menu lists every existing registry tag with its usage count, filters as you type, and offers a marked (new) chip when the name matches nothing — adding and removing tags works without page reloads.

The content is editable too, but only by replacing it, never by silent drift:

• Reupload swaps the track for a new file. The entry keeps its id, votes, comments, and dependants; title, tags, facets, and content are taken from the new file. The new content is validated exactly like a first upload (and rejected if it duplicates a different entry).
• Add dependency appends an @import of another registry track (picked from an autocomplete list) to this track and re-stores it.

The uploader (or an admin) can also delete an entry — from its edit page or straight from the listing. Deleted tracks move to deleted/ inside the data directory; they are never destroyed.

Comments

Any visitor can leave a comment on an entry, with an optional display name (shown before the timestamp, or anonymous if left blank); comments appear on the entry page. A comment's own author (recognized by the visitor cookie, marked you) or an admin can delete it — no one else. Every posted comment is also appended to an append-only comments.log in the data directory (one JSON object per line), kept even after the comment is deleted, so the operator can review problematic ones. That log stays local: it is gitignored and never mirrored.

Browsing, search, votes

The index filters by at most one author (?author=…, from a clickable author name), at most one content facet (?auto=waves), any number of free tags (?tag=nes&tag=lead, narrowing by all of them), and a text search over title, author, description and tags — all combinable. Clicking a chip sets or adds that filter, and each active filter shows as a removable pill. Results are paginated at 24 per page. Sort criteria: newest, most downloaded, most liked (the default), best like/dislike ratio, most controversial; each reversible.

Anyone can vote 👍/👎 (one vote per visitor, toggleable). Downloads are counted per entry.

Listening: preview, play, remix, export

• Previews. Each entry page renders audio snippets on the server: the whole song, every layer solo, every local instrument (a short arpeggio, sung la for voice sounds), and every wave. Cached after the first request. A sung track's words (its # Subtitles) are listed as lyrics.
• Play. Links into plainaudio via URL fragment — hear a track in the browser without downloading anything.
• Remix / Import. Link into plainsong — #url=… opens a track in the editor to build on, #import=… pulls it in as an import.
• Export. Playable entries render to WAV or MP3 on the server.

Play, remix, import, and export open in a new tab, so a slow render or a jump to the editor never replaces the page you were browsing.

URLs

Git mirror

If the data directory is a Git repository, the server commits and pushes all track changes about once a minute — the registry doubles as a public, forkable library. Only canonical .track files are published; the rendered audio cache, deleted entries, and the JSON index (it contains visitor ids) are kept out via a generated .gitignore.

git -C data init -b master
git -C data remote add origin <public repo url>

Admin & moderation

A random admin token is printed on the server console at every start. An Admin link sits in the page header. Logging in at /admin allows editing and deleting every entry, and deleting any comment. Deleted tracks are moved to deleted/ inside the data directory, never destroyed; posted comments are additionally recorded in comments.log (see Comments) for after-the-fact review.

Running

trackyard [--address host:port] [--data directory] [--public-url url]
          [--player-url url] [--editor-url url]

Source: gitlab.com/porky11/trackyard (Rust, axum + maud + game-audio; MP3 export needs a C compiler at build time).