The warning's trill, and why it only sometimes came out

An LFO belongs to the DEVICE and not to a channel. There are two of them
against four voices, and a patch carries LFO settings the way it carries
everything else - so whichever patch was loaded last owns both of them,
for every voice at once.

The warning's trill is a saw LFO on the pitch. The patches on channel
three, the bang and the latch, carry an LFO that is switched off, and
they load at the moment they are used. So the first landing, docking or
crash of a run took the trill away and left a plain tone, and it was
right again next time the machine started. Correct until something
unrelated plays is the worst shape a fault can have.

The same thing had already happened silently at startup: the instruments
were set up in order, so the warning's LFO settings, written last, sat on
top of the rumble's and the rumble never had its own at all.

So nothing is set up once any more. Each sound loads its patch
immediately before its note - forty-odd writes at a moment already making
a sound - and is then whatever its patch says, whatever played before it.
Measured after a landing: 1056, 660, 516 hertz, then up to 1698 and down
again. Two sweeps of the saw, which is the trill.

What it does not fix, because it cannot: two sounds overlapping still
share the LFOs, so a warning going off mid-burn re-tunes the rumble for
as long as it lasts. With two between four that is the device.

Three checks at the device level, where the trap can be stated exactly: a
routed LFO bends a pitch (184 Hz against the 262 the note asked for),
another channel's patch takes it away (272, the note itself), and saying
it again gets it back (184). Written up in the Programming Manual beside
the LFO mode, since the next program to want two sounds will meet it too.

SplitBit Programming Manual.md

@@ -1148,6 +1148,26 @@ The consequence is worth knowing rather than fixing: a retriggered noise source
 repeatable, so every hit is literally the same noise, the way a sampler is. On a hi-hat that
 can read as machine-gunny. Where variation is wanted, leave that LFO or that voice free.
 
+### A Warning About Sharing Them:
+
+**An LFO belongs to the device and not to a channel.** There are two of them against four
+voices, so setting one from a patch meant for channel three changes what channel nought hears,
+immediately and for as long as nothing sets it back.
+
+That matters because a patch naturally carries LFO settings along with everything else - it is
+one instrument, and its LFO is part of how it sounds. A program that loads its instruments once
+at startup therefore ends up with whichever of them was written *last*, for all of them.
+
+The failure this produces is unpleasant to diagnose, because it is intermittent by nature: a
+sound is correct until some unrelated thing plays, and correct again next time the machine
+starts. A game here lost a warning's trill after the first landing of each run, because the
+landing's patch happened to carry an LFO that was switched off.
+
+**Load a patch immediately before the note that needs it.** A patch is forty-odd writes and
+this costs nothing at a moment that is already making a sound. What it cannot fix is two
+sounds overlapping - they still share the LFOs, and with two between four voices that is in
+the nature of the device.
+
 ### Knowing When It Has Finished:
 
 The status port's bit 0 is set while any channel is still sounding, so a routine can wait for