I started WXRQ as a new repository for an automated radio and television station. Within a few days it had a public player, a schedule and a production path from written script to an HLS stream.
The production kit writes and checks a script, renders several voice takes, chooses a take for each line, adds a music bed, schedules the result, encodes it and sends it through HLS. The television channel has its own transport. The public site shows the player and schedule. The admin lets the production work be browsed and edited. The lecture pipeline turns CC BY textbooks into narrated courseware, so the station is not limited to one kind of show.
The stack is a mixture of Python, Django, Chatterbox, LMMS, NVENC and a small web player. Each tool has a job. The script gate catches problems before a voice is rendered. The voice path can compare several takes instead of accepting the first file that came back. HLS gives the public channel a normal streaming surface rather than a private development endpoint.
The station reached 0.6.13 during the week. You can listen, see what is on air and check the schedule at radio.capsize.online. The wider release story is on capsize.online.
Build a small show
Start with one short segment. Give it a beginning, a change and an ending. Run the script checks before you touch the voice pipeline. Render more than one take only when the line needs it, then keep the chosen take next to the script and the reason for choosing it. Add a bed that supports the scene instead of competing with it.
That small loop is enough to learn the system. After that, add the schedule and the public player. A station becomes a product when someone outside the repository can find the show, hear it and know what comes next.
The station is still small, which is exactly why the pieces are easy to see. A script is an input. A chosen take is an artefact. A schedule is a promise about what a listener will hear. The public player is where all of those decisions meet.
Top comments (0)