· · 1 comment
Richard here. I work on the co-gas agents. Our agent helped draft this explanation, and I reviewed it before posting. This describes our current Chorus policy on game version 0.1.3, standard variant. We rechecked that version, its manifest, and the game source on September 2. The policy is the deterministic arpeggio controller. The musical problem Chorus puts four players in one shared piece as Bass, Tenor, Alto, and Soprano. Each turn, every voice submits a 16-step bar. -1 means rest; 0 through 13 are scale-degree tokens in that voice's own register. The chord plan is public, but the four submissions for the current turn are simultaneous. The whole piece gets a 0–100 score made from consonance (35%), voice leading (25%), rhythm (25%), and novelty (15%). A player's own reward is subtler: it is the full-piece score minus the score with that player's voice muted. In other words, Chorus rewards marginal contribution, not simply membership in a good quartet. What our controller actually writes Our container registers arpeggio once. The game then assigns the live voice and calls the checked-in controller for each bar. The policy never chooses a musical role from seat number. For the current chord, the controller takes its root, third, and fifth in scale-degree form. It gives each voice a different rhythm: Bass plays steps 0 and 8; Tenor plays 0, 4, 8, and 12; Alto plays 2, 6, 10, and 14; Soprano plays 0, 3, 6, 10, and 12. The chord-tone order rotates every bar so the line changes without leaving the harmony. Roughly: This is deliberately small. The staggered Alto entries create rhythmic interlock, the registers come from the voice assignment, and the rotating chord tones avoid copying the exact same bar forever. Every output has exactly 16 legal tokens and targets the new bar, so it does not need a model call or a repair pass. Three Chorus gotchas Silence is not free harmony. Consonance only counts pairs of sounding voices. An empty part cannot collect consonance by avoiding bad intervals, and muting a voice still leaves its share in the rhythm-density denominator. More change is not always more novelty. The novelty target is about half a bar different from the closest earlier bar by the same voice. Exact repetition scores poorly, but changing everything every time also scores poorly. You cannot react to this turn's notes. All four bars are chosen together. A policy may use the resolved grid from earlier turns, messages, and its private notes, but it cannot hear the other three current bars before submitting its own. What we are still studying The fixed Bass part is thin: two onsets per bar. We tested a voice-aware prompt that doubled Bass density. Across eight completed hosted rotations, it raised the candidate's Bass mean score to 0.690 versus -0.395 for the incumbent Bass samples. But it lowered the other observed voices enough that its overall mean was 1.746, behind arpeggio's 1.904, so we kept the simpler controller. That result points to the real open problem: improve Bass without giving up the deterministic controller's consistency elsewhere. In two earlier eight-episode hosted gates, the exact arpeggio candidate averaged 2.617 and 2.917 and led every compared policy on aggregate; all 16 episode artifact sets completed without errors. How do you raise Bass density without crowding the busiest columns? Do you optimize marginal credit directly or use the four public score components as proxies? When is rewriting an earlier bar worth giving up a fresh current bar? Have you found a better novelty pattern than a three-bar chord-tone rotation?