TECHNOLOGY / 003 · AN OPERATING SYSTEM

A broadcast chain,
built end to end.

MIDI playout. OBS production. Kick distribution. A server-side radio relay. Signed live metadata. Native Gopher. Public data systems. Here's how the parts connect.

FIG. 03 / ONE SIGNAL · TWO PUBLIC PATHS

NTPROGRAM
PRODUCTION

OBS → KICKLIVE AUDIOVISUAL BROADCAST

HLS → MP3 → ICECASTEXISTING RADIO STREAM

A SEPARATE SIGNED METADATA PATH
PLAYOUT → JSON + ICY → PLAYER DISPLAYS

PRODUCTION / DISTRIBUTION / METADATADOCUMENTED PATH

01 / AN OPERATING SYSTEM

A broadcast network, engineered end to end.

The interesting part is not a single piece of software. It is the chain: an instrument and playout system, a production workstation, a public video platform, a server-side audio relay, live metadata, and a growing collection of independently useful Internet services.

NITETIME.NET connects these parts while keeping their jobs distinct. The production computer makes the program. Kick carries the live audiovisual broadcast. The existing server extracts and encodes its audio for radio. A separate signed event path describes what is actually playing. Public websites and older Internet protocols make the work discoverable in very different ways.

This is a working, founder-led production network—not a claim of full automation. Automation takes care of repeatable steps; a human operator still directs and evaluates the result.

02 / THE BROADCAST CHAIN

One production. Two live outputs.

The signal path below is documented in the public technical notes and the operational record. It describes how the current production is connected, not live device telemetry.

01 / PLAYOUT & INSTRUMENT

MIDI drives the organ

Saved MIDI performance data controls the physical organ through a USB MIDI interface. The organ's audio is mixed and captured back at the production workstation over USB.

02 / PRODUCTION

Workstation builds the show

PipeWire routes captured audio into OBS alongside the video, graphics, and station presentation. OBS produces the audiovisual program for the live broadcast.

03 / TELEVISION

OBS sends to Kick

The workstation publishes the live program to Kick. Kick distributes it as a live audiovisual stream, including HLS segments used by downstream listeners.

04 / RADIO EXTRACTION

Server makes the MP3

The existing server relay reads Kick's HLS audio, uses FFmpeg to encode stereo MP3 at 128 kb/s, and publishes it to the existing Icecast mount.

05 / LISTENER DELIVERY

HTTPS carries the stream

Nginx delivers that same MP3 at nitetime.net/live.mp3 and the standalone radio host. It passes ICY metadata requests through to Icecast.

One radio stream, not a second station: the standalone player adds a dedicated listening interface. It does not add another Kick fetcher, encoder, Icecast mount, or audio pipeline. The original MP3 URL remains in service.

READ THE RADIO SYSTEM FIELD GUIDE ↗Published in NITETIME.NET's Gopher technical archive

TOOLS / CONNECTED TO THE PHYSICAL WORLD

Not just software. A working production workshop.

Here are some of the exact instruments, programs, and formats behind the broadcast. The pieces span a home organ, professional audio hardware, Linux software, vintage computers, and a separate local rendering machine.

01 / LIVE MUSIC PLAYOUT

Lowrey LC/20 + nitetime-midi

A Lowrey Jamboree LC/20 is controlled by saved MIDI through a USB MIDI interface. The active Linux application uses Python and FastAPI for the player and control API, Mido/RtMidi for MIDI, ALSA for device access, and PipeWire for the audio graph. FFmpeg prepares paired recordings as 48 kHz stereo PCM; the MIDI scheduler follows the audio output clock and reported latency so the recording and instrument performance stay together.

A Yamaha MG-XU mixer carries the organ and playback into the captured broadcast mix. A September 2026 Gopher article reports more than 107,000 imported files in the local MIDI source library; that is a personal research and curation pool, not a count of finished original tracks or approved broadcast pieces.

BROADCAST WORKSHOP NOTES ↗THE LOWREY SYSTEM ↗

02 / ANALOG PICTURE, DIGITAL PIPELINE

FireWire camera → OBS

The documented camera chain uses a Sony DCR-TRV315 DV camera, FireWire capture with dvgrab, FFmpeg, and a Linux V4L2 loopback device as a camera source for OBS. At the last detailed inventory, the loopback input was 640 × 480 at 30 fps. OBS also takes the Yamaha/PipeWire program audio and sends the finished audiovisual show to Kick.

This is a real mix of consumer-era video hardware and current Linux software. The camera path is a production input; it does not claim the public stream is delivered at that same input resolution.

SEE THE SIGNAL PATH ↗

03 / EIGHT-BIT GRAPHICS LAB

Commodore 64 + 128

Original Commodore 64 and 128 hardware is used for screensavers, digital-sign loops, telemetry displays, visualizers, and demoscene-style motion. Programs are written in BASIC or 6502-family assembly and cross-assembled with ACME under Ubuntu Linux. Captured visuals can feed station elements; old hardware contributes a distinct production grammar, while the live program is assembled by the modern Linux/OBS chain.

OPEN THE GOPHER WORKSHOP ↗

04 / LOCAL CREATIVE COMPUTE

Blender + local language model

A separate Linux production node has used Ollama 0.40.4 with the Qwen3.5:0.8b Q8_0 model for local draft assistance, Blender 5.0.1 for procedural scene rendering, and FFmpeg 8.0.1 for assembly. The documented nine-episode review campaign rendered on CPU. A nine-episode Contagious Fear review-render campaign completed 26,640 source frames; frame hashes matched their records and all nine MP4s passed full decode checks.

Those files are local review masters—not approved or published episodes—and retained temporary synthetic audio. This is a measured production prototype, not a claim that a finished series is already on the network.

HOW THE ATLAS DOCUMENTS THE PRODUCTION MACHINERY ↗

Hardware and project measurements above follow dated operational records and published Gopher notes. Device modes and software versions can change; source-library counts describe imported material, and render verification is not editorial approval.

03 / METADATA SIDE-BAND

The stream carries sound.
A signed feed carries context.

Track titles and program transitions travel alongside the audio as a separate, authenticated data path.

A monitor on the broadcast workstation reads the actual PLAYING rundown item—not the next item in the queue—and publishes events for supported music, weather, commercial, DJRC, and station transitions. The workstation signs each event with Ed25519; the server verifies it before accepting it. Private signing material stays on the source machine.

After an approximately twelve-second hold to account for broadcast and stream delay, the server updates a small public JSON document and the MP3's ICY StreamTitle. The radio website uses the JSON feed to update its receiver, page title, and Media Session metadata for compatible phone controls. No audio is restarted when a title changes.

Two measured source-to-public updates arrived about 12.0 and 12.3 seconds after their source timestamps. That supports the configured hold as a practical approximation; individual Kick, network, player, and car buffers mean it is not exact audio synchronization for every listener.

ED25519 EVENT SIGNING→SERVER VERIFICATION→DELAYED JSON + ICY→WEB / PHONE / RADIO CLIENTS

OPEN THE RADIO RECEIVER ↗VIEW PUBLIC NOW PLAYING JSON ↗

PUBLIC EVENT SHAPEREAD ONLY / SANITIZED

{
  "kind": "music",
  "title": "Current program item",
  "artist": "when supplied",
  "source": "playout",
  "observed_at": "source start time"
}

Example structure only. Authentication headers, signatures, keys, and private endpoints are deliberately omitted.

JSONICYMEDIA SESSION

04 / INTERNET SERVICES

More than a website stack.

Separate tools give each kind of media and interaction a fitting home—while a common visual identity and public navigation make the network feel connected.

VIDEO / MEDIA LIBRARY

Published media, on demand

The video archive runs as a distinct MediaCMS destination. Its documented server stack pairs PostgreSQL with Redis and Celery background workers; Nginx handles the public HTTPS entry points. The main site and radio player remain lightweight presentation layers with their own static paths.

EXPLORE THE VIDEO ARCHIVE ↗

NATIVE + WEB GOPHER

The old Net has new doors

Gophernicus serves native Gopher. A purpose-built browser gateway presents the same text-first archive on the web. Veronica indexes published menus every ten minutes; a separate safe aggregate status collector refreshes its summary each minute.

READ THE PUBLIC SYSTEM OVERVIEW ↗

INTERACTIVE ATLAS

A map backed by a data model

The Known Universe is a custom WebGL experience, with destinations, tour order, and typed relationships stored as structured data. Its public activity indicators use read-only, approved status sources; illustrated machine activity is labeled as illustration.

EXPLORE THE KNOWN UNIVERSE ↗

WEATHER / ASTRONOMY

Source data, with its limits intact

A small Python collector combines NOAA NWS forecasts and station observations with NDBC marine readings. Official U.S. Naval Observatory phase times anchor the moon calendar; browser-side SunCalc 1.9.0 estimates local sun/moon position and illumination. The collector refreshes every 30 minutes, preserves source timestamps, marks stale or missing data, and never presents a grid forecast as a beach-break measurement.

EXPLORE THE SURF REPORT ↗

THE KNOWN UNIVERSE / TECHNICAL TOUR ↗PUBLIC SYSTEM OVERVIEW ↗PUBLIC AGGREGATE STATUS ↗

05 / ENGINEERING PRINCIPLES

Make the signal useful.
Make the claims precise.

Small, separable components. The public player is static HTML, CSS, and JavaScript; a metadata sidecar updates titles independently of the audio; Nginx joins existing local services at public HTTPS routes. Routine presentation changes do not require restarting the station's audio path.

Publish from evidence. The Gopher comic release workflow checks a public manifest, complete file inventory, and SHA-256 checksums before publishing approved text material. The creative source can use AI assistance, while the deterministic gate prevents incomplete packages from being treated as finished releases.

Keep private systems private. The sitemap exposes a curated directory and only approved read-only status routes. It does not disclose credentials, private addresses, administrative interfaces, prompts, process lists, or machine heartbeats. NITETIME-RAM carries versioned documentation and operator messages; it is not the live audio/video path or a real-time telemetry bus.

AI-assisted engineering and production. AI coding assistance, including Codex, helps one developer build and maintain the software that ties the operation together. A separate local Ollama/Qwen setup has supported selected draft work on an offline production node. Generated material remains a draft: trusted code validates its structure, and people retain creative, factual, and release approval.

Human judgment stays in the loop. AI can help with code, research, and production experiments. It does not turn unchecked claims into news, decide what belongs on air, or remove the need for creative and editorial responsibility.

06 / IN DEVELOPMENT

Extend the system through real work.

The operating network is also a testbed for future services. These are opportunities under evaluation, not claims of products already deployed for clients.

APPLICATION / 01

Digital signage

Information channels for lobbies, waiting rooms, and shared spaces.

APPLICATION / 02

Managed channels

Branded programming and information feeds for organizations.

APPLICATION / 03

Production services

Media production, broadcast automation, and technical consulting shaped by the systems already in operation.

The public documentation describes system roles and data flow, not a full internal topology. Infrastructure and platform components may evolve. Operational state is published only where a reliable, public-safe signal exists.

THE TECHNOLOGY IS A WORKING EXPERIMENT

Follow the signal.
Inspect the systems.

EXPLORE THE INTERACTIVE ATLAS ↗DISCUSS A PROJECT ↗

A broadcast chain,built end to end.