Från “ström” till “station”: scheman, jinglar och tanken på olika tider på dygnet.
Under de första åren var det fortfarande en ganska traditionell MP3-radio, men jag började gradvis vilja styra mer än bara vilken fil som kom härnäst. Jag ville att vissa saker skulle hända vid vissa tider. Jag ville kunna lägga stationselement mellan låtar. Jag ville kunna ha ett annat sound på kvällen än mitt på dagen.
Det var här de första schematankarna dök upp. En enkel spellista är bara en lista. En station behöver regler: när får listan spelas, hur ofta får samma artist komma tillbaka, hur ofta ska ett stations-ID höras, vad händer om en låt är för lång och nästa block egentligen ska börja?
Jag testade flera sätt att få detta att fungera. Några var rena tidsregler. Några byggde på separata listor. Några byggde på att en spelare helt enkelt fick byta källa vid ett visst klockslag. Alla fungerade i någon form, men ingen löste hela problemet.
Det var ett återkommande mönster: ju mer jag försökte tvinga in “radio” i en vanlig spelkö, desto fler undantag behövdes. Det blev en tidig signal om att showlogik senare måste bli en egen sak.
Det första schemat såg enklare ut än problemet var
Jag började med typiska tidsregler: den här listan gäller här, den där listan gäller där. Men låtar känner inte till klockan. En sexminuterslåt som startar 17:58 kan lätt sabotera ett program som ska börja 18:00 om ingenting planerar framåt.
Först försökte jag lösa det med hårda bryt. Sedan med mer luft runt blockgränser. Sedan med att förbjuda vissa låtar nära gränsen. Varje variant lärde mig en del, och senare kunde jag kombinera idéerna i Show Engine i stället för att lägga fler specialfall i playlisten.
Schemaexperimenten skapade mina första “regler ovanpå regler”
När jag började tidsstyra innehåll dök problem upp som inte fanns i den enkla MP3-perioden. En lista kunde vara rätt för klockslaget men fel för övergången. En jingle kunde vara tillåten enligt sitt intervall men hamna precis före ett planerat programbyte. En låt kunde vara helt rätt musikaliskt men för lång för det tidsfönster som återstod.
Jag löste först sådant lokalt. Ett extra villkor här, en spärr där. Det fungerar väldigt snabbt men bygger snart ett system där ingen enskild regel förklarar slutresultatet. Det var första gången jag fick känna kostnaden av specialfall.
Den erfarenheten är en stor anledning till att dagens kod försöker centralisera vissa typer av beslut. Showgränser ägs av Show Engine. Talk-kollisioner ägs av Talk Scheduler. Musikrecency ägs av Picker. När en ny regel ska in försöker jag först avgöra vilket av de lagren som faktiskt borde äga den.
Det är en ganska stor utveckling från de tidiga åren: då var fokus att få nästa beteende att fungera. Nu är fokus ofta att få beteendet att fungera utan att nästa beteende måste känna till specialfallet.