Website and brand

MusicStation has a product website at https://daw-musicstation.de. It shows the feature overview, the complete release history, the download area and the beta waitlist, and it carries this manual - every page in English and in German. Whatever the site does not answer, the project answers by mail at info@daw-musicstation.de. This chapter describes what the site offers, how the online copy of this manual is addressed and searched, and which form the brand, the home page and the icons of the site have.

The website

The site lives at https://daw-musicstation.de. Its entry page is a language chooser with the two links Continue in English and Weiter auf Deutsch. A small script sends a visitor whose browser prefers German straight on to the German version; everybody else stays. Both links work without that script, so the chooser is never a dead end. Every other page exists in both languages, under /en/... and under /de/..., and the language is a segment of the address and nothing else. No page sets a cookie and no page writes into the browser's storage, so nothing remembers a language choice for you; the language switch in the header is built from the address of the page you are on, and it keeps you on that same page when the language changes.

The header's main navigation (Home, Features, Releases, Download, Manual, Waitlist) and the footer's page column (Manual, Releases, Download, Waitlist, Contact, Privacy, Imprint) stand on every page. The parts of the site:

The home page (/<lang>/) opens with the product message, the two actions Join the waitlist and See all features, and the version and platform line below them. After that it lists the features that ship today and the ones that are in development, and it closes with the download teaser and the waitlist teaser.
The feature index (/<lang>/features/) with one page per feature (/<lang>/features/<slug>/). A feature page says what the feature does, which controls exist, the manual sections that document them and the limits that matter in practice. The availability badge next to a feature is derived from the site's feature data and never written on the page: a feature that ships carries Available since <version>, a feature in development is marked as planned and names the release it is planned for, and a feature without a promised release says exactly that and names no date at all. Planned features stand in their own group, so none of them can look shipped. The current release is MusicStation 0.3.0; the session view arrived in it.
The release history (/<lang>/versions/) shows every release of MusicStation with the release notes that shipped with it, newest first, and marks the running version as Current version. These are the same notes the application shows (see Release notes and What's New). Each version heading is its own permanent link, built from the version number with the dots replaced by dashes, so MusicStation 0.3.0 stands at /<lang>/versions/#v0-3-0. The page shows no release date: the project stores none, and none is invented. The Atom feed /<lang>/versions/feed.xml carries the same releases for a feed reader, and every page links it in its head.
The download area (/<lang>/download/) offers the published build for macOS on Apple Silicon (arm64, macOS 13 or later) together with the release notes of that version. While no build is published, the page states that plainly and points at the waitlist instead: an unconfigured download target means no public download yet, never a guessed file.
The online manual (/<lang>/manual/) is this manual on the web, chapter by chapter; the next section of this chapter describes it.
The waitlist (/<lang>/waitlist/) is the only form of the site that submits data - the search field of a manual page is a form as well, but it never sends a query anywhere. It asks for your e-mail address, optionally for what you are waiting for (macOS, Windows, Linux or the iPad remote) and for your consent, states the double opt-in - your address is stored only after you followed the link in the confirmation mail - and links the privacy policy. Sent without JavaScript, the form is an ordinary form submission and the page then tells you the answer; the comfort script only reports the sending state and the answer without leaving the page, and it is loaded only while the site has an endpoint for entries. While there is none, the form is visibly switched off with the reason, and the page names the e-mail address instead.
The contact page (/<lang>/contact/) collects the three reasons to write - questions about the beta, bug reports and press enquiries - and names the address for all of them: info@daw-musicstation.de.
The two legal pages (/<lang>/legal/privacy/ and /<lang>/legal/imprint/) are the privacy policy and the imprint. The imprint is the provider identification of a German website, with every operator detail marked as a placeholder because the project does not carry it; the privacy policy states what the site does as built, and nothing beyond that.

Scripts, cookies and third parties. The site is plain HTML and CSS. Exactly three scripts exist, each on the page that needs it, and every other page loads none at all:

the language suggestion of the chooser at /;
the search on the manual pages (see below);
the comfort script of the waitlist form.

None of the three is required. Without JavaScript the language links, the feature pages, the release history, the download area, the waitlist form itself and the whole manual - page list and table of contents included - still work. No page sets a cookie and no page uses the browser's storage (localStorage, sessionStorage or indexedDB). Nothing is loaded from a foreign origin: fonts, styles, images, scripts and the manual's search index are served by the site itself. There is no analytics, no advertising and no third-party service behind the site.

Workflow: from the site to a build

Open https://daw-musicstation.de and pick your language, or go straight to /en/ or /de/.
Read the feature index to see what exists today and what is still in development; a feature page links the manual chapters that document its controls, for example Session.
Open the release history and read the notes of the current version - they are the same notes MusicStation ▸ What's New shows in the application (see What's New).
Go to the download area: take the published build, or leave your address on the waitlist while there is none.
Read a chapter in the online manual (see below), and keep the address of a section you want to return to - it stays valid.

The online manual

The website carries this manual: every chapter, in English and in German, rendered when the site is built from the same files the application bundles. Both copies therefore describe the same controls in the same sections - only the frame around the text differs.

The manual home is /<lang>/manual/; it is the table of contents the application knows as Contents. Each chapter has a page of its own at /<lang>/manual/<page>/, where <page> is the chapter's path inside the manual without its file extension: this chapter is the file web.md, so it stands at /en/manual/web/ - and, in the German manual, at /de/manual/web/. The page list in the sidebar lists every chapter of that language in the order of the repository, and the previous and next links below the text follow the same order.

Every section has its own address. The anchors of the manual - the ids the source writes in front of a documented control - are kept verbatim, and they are the same ids the application's help uses. A section is therefore reachable at the same address in both places, in the form /<lang>/manual/<page>/#<help-id>. The language setting, for example, stands at /en/manual/interface/settings/#settings.language, and the German manual has it at /de/manual/interface/settings/#settings.language. A heading without an anchor of its own belongs to the anchor above it: both sections of this chapter are part of the chapter anchor section.web, and the table of contents at the top of the page links exactly that anchor.

F1 and the online manual. F1 opens the manual that is part of the application, at the id of the control under the pointer (see Help for the control under the pointer); the application carries its own copy of the text and needs no network connection for it. Because the website keeps the same id as an anchor, the section F1 shows you is also reachable in the online manual at the address above - same page, same id, only the site's prefix in front of it.

The search. Every manual page has a search field in its sidebar. It searches the manual of the page's language: the page loads the index /<lang>/manual/search-index.json - one entry per anchored section, with its page, its anchor, its heading and a short extract of its text - and matches your query against it in your browser. The index is written from this manual while the site is built and served from the site's own origin, so no request goes to a search provider and no third party is involved. Case and umlauts are folded, which is why a typed u finds ü and a typed strasse finds Straße; a hit in a heading weighs more than a hit in the body, and at most twenty hits are listed, each of them a link to its section. The field needs JavaScript, and the hint right below it says so. Escape clears it and the result list. Without JavaScript you lose the field and nothing else: the page list and the table of contents are plain links in the built page and still get you everywhere.

Workflow: from a chapter to one section

Open /<lang>/manual/ - the same table of contents the application's help starts from.
Pick a chapter in the page list, or follow the links inside a chapter.
On a long chapter, use the table of contents at the top of the page to jump straight to a section.
Do not know which chapter? Type a word into the search field; every hit links to its section. Without JavaScript, use the page list instead.
Keep or share the address of a section, for example /en/manual/interface/session/#session.grid. The anchor in that address is the id the application's help opens the same section with.

The brand mark

The mark of MusicStation is the session grid, the motif the product is built on: a clip grid of five columns by four rows. A clip slot is 16 units wide, the gap between two slots is 4, the corners are rounded with a radius of 3, and the drawing area is 0 0 96 76. The lit slots spell an M - column 0 and column 4 complete over all four rows, plus the slot of column 1/row 1 and the slot of column 3/row 1 - and every other slot is unlit. One slot of the grid is playing: the slot of column 2/row 2, the middle of the letter. Lit slots take the accent colour, unlit ones the slot grey, and the playing slot the amber of the palette (#faab3f on the mark's dark ground). The grid is the motif of the session view (Session grid), reduced to five columns by four rows and to the one playing slot the mark needs.

The grid never changes which slots are lit: the mark is not rotated, not stretched and not outlined, and a second drawing of it exists nowhere. Only the playing slot may move - where motion is allowed it pulses once per bar - and where the operating system asks for reduced motion the grid stands still and keeps showing the lit M and the amber playing slot. Around the mark lies its clear space of one cell (16 of its 96 units) on every side; it is drawn from 24 pixels wide upwards, and only the small favicon master goes down to 16 pixels. The mark exists in two versions: mark.svg for dark grounds and mark-light.svg for light ones, which uses the second set of the colour table (#f9fafb, #0072d5, #ced1d5, #e57600).

On the website the mark is recoloured through its slot classes - msh-on for a lit slot, msh-off for an unlit one and msh-hot for the playing one - and every slot keeps the colour value of its file as well, so the same drawing reads where no stylesheet applies: in a downloaded file, in a preview image or in a program without CSS. No template of the website carries a colour of the brand, and no copy of the mark lies in the website's own sources: it is read from docs/brand/ while the site is built, and a master that does not parse stops the build instead of shipping a half-drawn mark.

Next to the mark stands the word mark MusicStation - Music at weight 800 and Station at weight 400, set in Archivo at the expanded width of 118 percent and the letter spacing of -0.01em. The height of the mark equals the cap height of the word mark, and the gap between the two is one cell of the mark. The font belongs to the site and is served by the site itself; the writing stays real text, so it stays sharp on every display and can be read and selected. Mark and word mark together are the lock-up: the mark first, the word mark second. It stands in the header of every page of the website; the two preview images a shared link shows carry the mark beside the product message and the site address. The window of the application itself keeps its system title, so the lock-up belongs to the website and not to the title bar of the program.

The mark is also the app icon of both applications, and each of the two is derived from its own master in docs/brand/ - never drawn a second time:

Where	The icon
The macOS application	`ui/src-tauri/app-icon.png` (1024 x 1024, derived from `docs/brand/app-icon.svg`) and the icon set of the bundle built from it (`ui/src-tauri/icons/`, among them `icon.icns` and `icon.ico`)
The iPad app	`ios/App/Assets.xcassets/AppIcon.appiconset/AppIcon-1024.png` (derived from `docs/brand/app-icon-ios.svg`; the rounded corners are cut by iOS itself)

Both are files and never a live surface: they follow neither the accent colour nor the theme nor the UI scale of a device, and they never animate. Both show the same grid with the lit M and the amber playing slot and differ in their frame only: the macOS icon puts the mark on a rounded tile that is inset in the square canvas, the iPad icon fills the whole square, because iOS cuts its corners itself. Every icon of the product comes from the masters in docs/brand/.

The home page hero

The home page of a language (/<lang>/) opens with the hero: the product message, the two ways on and the animated clip grid. It is the first section of the page and it carries the page's only <h1>; the grid is not decoration but the brand's motif - its lit slots are the mark's M, read from docs/brand/mark.svg while the site is built and placed into a session grid that is larger than the mark itself, eight columns by six rows. One clip runs through the two outer rows: a slot arms, launches and stops in steps of one bar, inside the eight-second cycle of four bars that the stylesheet runs at 120 BPM, and the bar under the grid shows where that clip stands in the cycle. The hero is as tall as its content, nothing in it depends on the height of the window, and it needs no JavaScript; on a phone the message stands above the grid, and from a wide window the two stand side by side. The grid and the bar carry an accessible description each in the language of the page, because the running demo itself is decoration.

The hero shows	What it is
The headline	the product message and the page's only `<h1>`: the four workflows MusicStation unifies in one application - Cubase-grade MIDI, clip launching as in Ableton, the efficiency of Logic and analog summing as in LUNA
The subline	the one sentence under the headline: what the product is and which platform it is built for first
The two actions	Join the waitlist (to `/<lang>/waitlist/`) and See all features (to `/<lang>/features/`) - two ordinary links, so both work without JavaScript
The release line	`Version <version> - macOS on Apple silicon`: the release the site was built from - the version of the repository that the About dialog names as well - and the platform the product runs on first
The animated clip grid	eight columns by six rows of clip slots; the lit slots spell the mark's M and the playing slot of the mark keeps its amber (it pulses once per bar). The two outer rows are the lanes of the running clip: an empty slot is armed first (it lights up dimmed), launches at the next bar line, plays one bar and stops at the bar line after that - every step of the demo lies on a bar line of the eight-second cycle
The progress bar	the thin bar under the grid (`role="progressbar"`): it sweeps once per cycle, in step with the running clip, and shows how far the four-bar demo has come
The screenshot place	while no capture of the session view is published the hero shows the animated clip grid alone - no substitute drawing and no empty box keeping a place for one; the capture appears here as soon as one is published
Reduced motion	with `prefers-reduced-motion: reduce` the hero stands still in one still frame: the grid keeps the lit M and the amber playing slot, the pulse and the sweep stop, and the progress bar rests in the middle of its cycle

Icons and favicons

A visitor's browser asks for icons as well, and the build of the site answers from the same masters: every icon and every favicon of the website is generated while the site is built, taken from the mark in docs/brand/, and nothing of it is committed to the repository or drawn a second time. A master that cannot be read stops the build, so a page never ships a half-drawn icon.

The file	What a browser shows
`/favicon.svg`	the vector favicon: the small form of the mark for the tab, taken from the favicon master for 32 pixels
`/favicon.ico`	the icon container, for browsers that ask for a container instead of a vector file; it carries three frames of the favicon, 16, 32 and 48 pixels wide
`/apple-touch-icon.png`	the Apple touch icon a home screen uses, 180 pixels wide, taken from the iPad app-icon master - the full-bleed square whose corners iOS cuts itself
`/site-icon.webmanifest`	the web app manifest: the product name as `name` and `short_name`, the two icons of 192 and 512 pixels with their sizes and their media type, the standalone display and the ground colour of the brand for the theme and for the background
`/og/en.png` and `/og/de.png`	the two preview images a shared link shows, one per language, 1200 by 630 pixels: the mark, the product message of that language and the address of its feature overview

Every page names four of them in its head, in this order: the vector favicon with its media type, the icon container with the sizes of its three frames, the Apple touch icon and the web manifest. Next to them the head names the preview image of its own language with its size and a short description of the card, so a link shared from the English part of the site shows the English card and one shared from the German part the German card. The two pages without a language of their own - the chooser at / and the error page - point at the English image. The manifest is the one file of the set that belongs to no language: it is written once for the whole site and names the product, not a page.

The two favicon masters are drawn for the pixel grid: favicon-32.svg serves the small sizes from 24 to 48 pixels and favicon-16.svg the 16 pixel icon, and their slots are tuned for that grid. The icons the two applications carry are the opposite case: they are committed files inside the two bundles and are regenerated from the same masters in docs/brand/ whenever the mark changes. The rule is the same for all of them - derived from the one master and never drawn a second time.

Nothing of this set is committed: the build writes the files into the output of the site, and a rebuild after a change to a master writes them again, so a stale icon cannot exist. A copy of the mark under website/ exists nowhere - docs/brand/ stays the only place the brand is drawn.