static process archive · v02
A 64-bar UK garage beat built from programmed 2-step drums, phrase-level variation, and a final rendered arrangement. The raw source samples are intentionally not included in this website.
live dramatic visualiser
how it was made
The track and site were made as a compact human–AI production workflow. The important point is not that a finished garage piece appeared automatically, but that a few plain-language requests were turned into a repeatable process: inspect the container, generate MIDI, render audio, integrate samples, document the method, then replace a failed pre-rendered video idea with a live browser visualiser.
The first question was about what the container could actually do for music. The useful route was Python: MIDI generation, WAV rendering, DSP-style processing, waveform analysis, and static file export rather than a live DAW or plugin host.
The first musical brief was a 64-bar garage beat with variations every four and eight bars. A Python script generated a swung 2-step drum pattern with syncopated kicks, snare and clap backbeats, ghost notes, open-hat movement, four-bar fills, and eight-bar turnarounds.
The uploaded sample pack was inspected for file names, durations, sample rates, loop lengths, and likely musical roles. The samples were not published into the site; they were used locally as private source material during the render stage.
The project was moved to 140 BPM because the supplied loops lined up cleanly at that tempo. Several files matched one-, two-, four-, eight-, or sixteen-bar divisions, so the arrangement could avoid unnecessary time-stretching.
The generator script treated the job like an offline mini-DAW. It loaded local WAV files, chopped kick, snare, and hat material into one-shots, scheduled MIDI drum events, placed musical beds and accents, applied simple filtering and gain, then rendered the final stereo WAV and MIDI.
The result was wrapped as a static site with a splash player, waveform image, process notes, abbreviated transcript, arrangement map, metadata, and the Python generator script. The raw source samples remain excluded from the public package.
A pre-rendered MP4 visualiser was tried first, but the container timed out on more dramatic full-frame renders. The better implementation is now a live canvas visualiser that runs in the browser and syncs directly to the audio element.
The final package is named ukg-v02. It contains the finished WAV, MIDI, waveform, metadata, generator script, static page, styles, and browser visualiser code. It does not contain MP4 renders or raw sample files.
abbreviated build transcript
This is a compressed transcript of the collaboration. It is edited to show the decision path rather than every operational detail: the user steered the brief, the assistant generated scripts and assets, and the implementation changed when the first visualiser approach was not good enough.
What can the container do for MIDI, synthesis, and DSP?
It can generate MIDI, render WAV files, run Python DSP, analyse audio, draw waveforms, and create static files. It is better as an offline render environment than as a DAW.
Create a 64-bar garage beat with variations every four and eight bars.
A generated Python routine produced a 2-step drum structure with swung sixteenths, syncopated kicks, ghost snares, fills, and turnarounds, then exported MIDI and a simple preview WAV.
Use this sample pack and integrate it into the beat.
The uploaded audio was inspected, the project was moved to 140 BPM, and the final render was rebuilt using private samples as drum hits, loop beds, accents, and transition material.
Turn the final result into a static information website and show how it was made.
The site was built around the final WAV, MIDI, waveform, process explanation, transcript, and generator script, while excluding the raw samples.
The visualiser needs more drama, but the render is timing out.
The video-render approach was replaced with a live JavaScript canvas visualiser. It uses the audio playback clock to trigger stutters, grid cuts, tunnel cuts, waveform bursts, glitch slices, and flashes at four- and eight-bar points.
implementation
The included Python script is a reconstruction of the build process. It expects the private sample pack locally, loads WAV files, resamples where needed, slices useful sections, builds a 64-bar arrangement, schedules MIDI notes, mixes the audio offline, applies simple bus shaping, and exports the final WAV and MIDI.
The site itself is plain HTML, CSS, and JavaScript. The splash area puts the live visualiser first, then the final audio player and downloads. The rest of the page explains the build, shows the transcript, maps the 64-bar structure, and exposes the generator script.
The visualiser is not a pre-rendered video. It uses a canvas, the Web Audio analyser, and the audio element’s current playback time. Four-bar and eight-bar positions trigger different animation modes, so the dramatic cuts stay aligned without relying on a long MP4 render.
The script is included to make the production method inspectable. It does not include the private source samples, but it shows how the artefact was assembled: tempo alignment, drum scheduling, loop placement, transition accents, final render, MIDI export, and metadata creation.
Download build-track-v02.py
PROJECT_NAME = "ukg-v02"
TEMPO_BPM = 140
BARS = 64
# Load private local samples.
# Chop drum one-shots and fit loop material to bar lengths.
# Schedule swung 2-step MIDI events across 64 bars.
# Add four-bar fills and eight-bar turnarounds.
# Render the final WAV and matching MIDI.what changed from the earlier site
The project is now consistently named ukg-v02 across the page title, filenames, README, metadata, and generator script references.
The page no longer presents the visual layer as a rendered video. It describes and uses the live canvas implementation that was chosen after the MP4 route proved unreliable in the container.
The process now covers the actual chain: tool check, beat generation, sample inspection, Python arrangement, static site packaging, visualiser failure, and final browser-based solution.
arrangement map
The musical arrangement and the visualiser share the same clock. Four-bar points create shorter fill-style interruptions, while eight-bar points create stronger turnaround cuts. The final visual layer is therefore part of the documented artefact rather than a separate decorative video.
technical notes
The package is deliberately small and static. It contains the final rendered WAV, the matching MIDI, a waveform image, metadata, the page files, the JavaScript visualiser, and the Python generator script. It does not contain the private sample pack, individual source samples, or pre-rendered MP4 visualisers.
ukg-v02/
├── index.html
├── styles.css
├── script.js
├── scripts/
│ └── build-track-v02.py
└── assets/
├── ukg-v02-final.wav
├── ukg-v02-final.mid
├── ukg-v02-waveform.png
└── metadata.json