jupyter-tts-alerts

Written during my dissertation, where a single pass over the pipeline took six hours or more. I spent a lot of that at the desk checking whether it was still alive — or discovering it had died on cell 9, forty minutes earlier.

The idea came from an anecdote about Pixar’s render farm during Toy Story, where machines were set to play animal noises as jobs completed. The room told you how the render was going without anyone watching a screen. Same problem, much smaller scale. It hooks IPython’s cell events, so nothing in your notebook has to change.

Non-intrusive by default. Cells under five seconds say nothing, so you aren’t narrated at while iterating. Errors always announce regardless of runtime.

Errors use a different voice, and that matters more than it sounds. If everything is one voice you have to parse the sentence to know whether it went well — which means stopping what you’re doing and listening. A different voice tells you the outcome before the words arrive.

Works — used daily through a dissertation’s worth of long runs, which is the only test that mattered at the time. It isn’t packaged yet: %run notebook_tts.py with the file alongside your notebook is clumsy, and proper pip install support is the main thing outstanding.

Known rough edges: errors are announced twice, because set_custom_exc and post_run_cell both fire on a failing cell and each increments the counter — so a crash says “Error in cell 4” and then “Error in cell 5”. Cosmetic, but it also means the cell numbers drift after the first error. Engine detection looks for espeak-ng, espeak and spd-say, so it’s Linux only; macOS say and Windows SAPI would each be a small addition. Two distinct voices need espeak — on spd-say, success and failure sound the same.