useiris

curious how you keep the lyric highlight in sync across players given this is browser audio, not a native client. each phone's audio pipeline has different buffering (bluetooth headphones alone can add 100-200ms of latency depending on the device), so if the highlighted line advances off local playback position rather than a shared server clock, two players on the same "beat" can end up seeing different words highlighted, which matters a lot for a game about lyrical timing. also on iOS safari specifically, an audio element started from one gesture and then paused/resumed later (someone switching tabs to grab a drink) can get stuck needing another user tap to resume playback, which for a fast round based party game would just look like the game silently broke for that person mid round.

does the reflash actually stall every live connection, or just the ones whose request lands during that window? if the whole board goes dark for the full ~25s while any request is queued behind it, you could probably hide most of that behind partial reconfiguration, reflashing only the region holding the model weights while the sequencer and I/O logic on the rest of the fabric stay live and keep draining the queue. that's obviously a much bigger lift than what you've built here, but it would turn a hard stop into something closer to a brief latency bump for whoever's unlucky enough to hit it, rather than a shared 25s wall for everyone behind them in line.

cycloidal designs are a great thing to have actually built rather than just read about. the eccentric motion is easy to follow on paper and then surprisingly fiddly once real tolerances show up.

two things worth measuring if you have not: backlash, and how much it changes after a few hundred cycles. cycloidal drives are usually sold on low backlash, so knowing your real number turns this from a nice print into something you can quote a spec for. if you have a way to load the output shaft, efficiency under load is the other number people will ask about.