Skip to main content

Module milk

Module milk 

Source
Expand description

The MilkDrop runtime: compiled EEL2 programs, the machine that executes them, and the driver that turns their output into warp-mesh parameters (ADR-0113).

No .milk text, no HLSL and no translator is anywhere in this module. Conversion happens ahead of time in milkconv, which never ships; what reaches a binary is bytecode, a stack VM, and the driver below.

§The execution model, which is MilkDrop’s

A bundle carries three programs over one shared register file:

  1. per_frame_init runs once, when the preset loads. It is where a preset seeds the q variables and its megabuf.
  2. per_frame runs once per frame, after the host has written this frame’s audio and clock into the input registers. What it leaves in the output registers is the whole-mesh transform, and what it leaves in q1q32 is the bridge to the program below.
  3. per_vertex runs once per mesh vertex, starting each time from the register state per_frame left — so q1 reads the same value at every vertex, and a write inside the program does not leak from one vertex to the next.

That third property is why EelProgram::written_registers exists: the restore is over the registers the program can actually write, not over the whole file, which at thousands of vertices per frame is the difference between a memcpy that matters and one that does not.

§Rates: MilkDrop is per frame, this engine is per second

The single most consequential translation in the conversion, and it is here rather than in the converter. MilkDrop’s zoom, rot, dx, dy, warp and decay are all per rendered frame: a preset written on a machine running 30 fps drifts at half the speed on one running 60. This engine’s vocabulary is per second throughout (ADR-0019), which is what makes a look identical on any display.

So the driver converts, per frame, using the frame’s own measured dt: a factor becomes v^fps and a rate becomes v * fps. A preset authored against MilkDrop’s nominal 30 fps therefore moves at the speed its author saw, on any refresh — and a converted preset does not have to carry the assumption in its bytecode. NOMINAL_FPS is the frame rate the fps variable reports to the program, for the same reason: a preset that reads fps and divides by it is compensating for a cadence, and telling it the truth about a 144 Hz display would double-compensate.

Modules§

bytecode
The bytecode an EEL2 program compiles to, and its text encoding.
outputs
The named values a MilkDrop program hands back, as one table (Plan 0100 Phase 4).
shader
The converted-shader interface (Plan 0100 Phase 6): what a translated MilkDrop 2 warp/comp fragment shader may bind, the uniform block behind its ~40-name input surface, and the naga gate every bundle shader passes at load.
vm
The stack VM that executes an EelProgram.

Structs§

ElementSpec
The structural numbers a custom element’s geometry is sized from — the parts of a MilkElement the draw layer needs and the VM does not.
MilkBundle
A converted preset’s compiled programs: what a bundle carries beyond an ordinary Ritmolux preset.
MilkElement
One custom wave or shape: its three programs and the structural numbers that size its geometry.
MilkRuntime
One loaded bundle’s live state: the VM’s arena and the resolved indices.

Enums§

BundleError
What is wrong with a bundle, as a surfaced load error.
ElementKind
What a custom element draws, which decides which of its programs run and how its outputs are read.

Constants§

DEFAULT_QUANTIZE_STEPS
The 8-bit feedback target every MilkDrop preset was authored against (ADR-0118): 256 levels, 255 steps between black and white.
MAX_ELEMENTS
How many custom waves, and how many custom shapes, the .milk format declares. Exactly four of each — not a budget, the format’s own shape.
MAX_SHAPE_INSTANCES
The most copies of one custom shape a preset may draw. MilkDrop’s own limit.
MAX_SHAPE_SIDES
See MAX_WAVE_POINTS.
MAX_WAVE_POINTS
The most points a custom wave may draw, and the most sides a shape may have.
NOMINAL_FPS
The frame rate the fps variable reports, and the cadence a per-frame rate is interpreted against.
Q_COUNT
How many q variables bridge the main program to a custom wave or shape.