Simply Music

Simply Music plays a three-voice arrangement of Pachelbel’s Canon in D using the SOUND command, with independent soprano, alto, and bass channels driven by score data stored in a three-dimensional array. The program reads note data (pitch register value, envelope register value, and duration) for each voice from DATA statements into a DIM s(PI,PI,400) array — a notable trick that uses PI (≈3.14, truncated to 3) to specify the array dimensions as 3×3×400. During playback, each voice is advanced independently through its note list on a countdown timer, allowing polyphonic scheduling without interrupts. The user can adjust per-voice volume levels (0–15) with on-screen bar-graph displays, and toggle a legato phrasing mode that controls whether notes are silenced between transitions.

---

Program Analysis

Program Structure

The program divides into four logical phases: initialization (lines 20–50), the main playback loop (lines 60–180), the keyboard handler (lines 190–270), and setup/data-loading subroutines (lines 280–410), followed by the score DATA at lines 420–510.

1. Initialization (lines 20–410): Sets display colors, allocates the score array, loads UDG graphics, and reads all three voice tracks from DATA into array s.
2. Settings UI (lines 290–340): Displays the title, volume bar-graphs for all three voices, phrasing status, and waits for ENTER before starting.
3. Playback loop (lines 60–180): Decrements per-voice countdown timers each iteration; when a timer expires, the next note for that voice is fetched and sent to SOUND registers.
4. Key handler (lines 190–270): Called mid-loop; processes S/A/B to cycle volumes and P to toggle legato phrasing, then updates the on-screen bar displays.
5. End-of-song (line 280): Silences all channels, prompts the user, then resets pointers and restarts.

The Score Array and the PI Trick

Line 350 declares the array with DIM s(PI,PI,400). Because BASIC truncates the floating-point value of PI (≈3.14159) to an integer for array dimensions, this is equivalent to DIM s(3,3,400). Using PI instead of the literal 3 saves one byte per occurrence — a compact coding idiom. The three “rows” of the first index map to soprano (1), alto (2), and bass (3); the second index selects pitch register value (1), envelope/waveform value (2), or duration (3).

Polyphonic Scheduling

Rather than using any interrupt-driven timing, the program implements a simple software scheduler. Each voice has a countdown variable (b, d, f) and a position pointer (b1, d1, f1). Each pass through the loop decrements all three counters (line 60). When a counter reaches zero or below, the next note is loaded for that voice and all six SOUND registers (pitch and envelope for each of the three voices, plus three volume registers) are written atomically in a single SOUND statement at line 180. This means all active voices are re-committed to the sound chip on every note advance of any voice.

Legato (Phrasing) Mode

The variable p acts as a Boolean phrasing flag. When p is non-zero (legato off — the display reads “Phrasing is not Legato”), lines 110, 130, and 150 silence the respective voice channel just before its note is replaced. When p is zero (legato on), those SOUND …,0 calls are skipped and notes run directly into each other. The label “not Legato” is slightly counterintuitive: pressing P toggles legato on, at which point the message changes to “Phrasing is Legato.”

Volume Controls and Bar-Graph Display

Variables vs, va, and vb hold the volume (0–15) for soprano, alto, and bass respectively. Lines 230–250 each draw a color-coded horizontal bar using repeated PRINT PAPER n;" "; characters: cyan (PAPER 5) for soprano, yellow (PAPER 6) for alto, and red (PAPER 2) for bass. The bar length equals the current volume value, with remaining cells filled in the background color to erase the old bar. Pressing the corresponding key cycles the volume upward, wrapping from 15 back to 0.

UDG Graphics

Lines 390–400 define two UDG characters (\a and \b) by POKEing eight bytes each into the UDG area. The DATA at line 390 encodes a simple animated cursor icon. Lines 80–100 alternate between printing \a and \b at a fixed screen position on every loop iteration, producing a pulsing playback indicator using the value of q as a flip-flop.

Variable Optimization

Lines 40 and later use pre-assigned variables n0, n2, and n8 (holding 0, 2, and 8 respectively) rather than literals throughout the DATA statements. Because BASIC stores variable names and their floating-point values separately from DATA, using short variable names in the DATA lines saves tokenized program space — though notably DATA items are stored as ASCII strings, so this technique actually saves bytes only in the source listing width, not in token storage. However, n0, n2, and n8 appear extensively in the DATA lines, and RESTORE/READ brings them in as numeric values correctly since the READ statement evaluates them as expressions.

SOUND Register Layout

The single SOUND statement at line 180 writes to eight registers simultaneously:

Register	Function	Source
0	Soprano pitch low	s(1,1,b1)
1	Soprano pitch high / waveform	s(1,2,b1)
2	Alto pitch low	s(2,1,d1)
3	Alto pitch high / waveform	s(2,2,d1)
4	Bass pitch low	s(3,1,f1)
5	Bass pitch high / waveform	s(3,2,f1)
8	Soprano volume	sv
9	Alto volume	av
10	Bass volume	bv

Rest notes are encoded as a zero in the pitch field of the DATA; when the program detects this, it sets the corresponding shadow volume variable (sv, av, or bv) to zero, silencing that channel while preserving the user’s chosen volume setting.

Notable Anomalies

• Line 250 displays the label “BASE” (missing the S) rather than “BASS” — a typographic error in the original listing.
• The bass array index uses s(PI,PI,f1) at line 160 rather than s(3,3,f1) or even s(3,1,f1) / s(3,2,f1). Since PI truncates to 3, s(PI,PI,f1) = s(3,3,f1) — fetching the duration field, not the pitch field. The actual pitch and envelope for the bass voice are read correctly in the SOUND call at line 180 via s(3,1,f1) and s(3,2,f1), so this line is only checking whether the pitch stored in column 3 (which is actually the duration value) equals zero to determine if a rest should be played. This likely works by coincidence since rest durations may be encoded as zero, but it is logically inconsistent with how soprano (column 1) and alto (column 1) rests are detected.
• The end-of-song condition at line 170 checks b1>n1 but d1>n2 and f1>n3 — using the variable n2 (value 2) as the alto note count and n3 as the bass note count. However, the actual note counts read from DATA are stored back into n1, n2, and n3 via the READ loops — wait, actually n2 is initialized to 2 and never overwritten, while the alto count from DATA is read into the FOR loop at line 370 but only used to control the loop, not stored into n2. This means the end-of-song test for alto (d1>n2, i.e. d1>2) will trigger after only 2 alto notes, far too early. In practice the song restarts after approximately 2 alto note advances, unless the bass voice triggers the condition first via f1>n3 — and n3 is never assigned at all, defaulting to 0, making f1>n3 true immediately. This suggests the end-of-song detection relies on the f1>n3 check triggering correctly only because n3 should have been set but was not, and the program may not play the full piece as intended.