After a protracted amount of hacking, it became clear that there's a minimum window size below which the FFT causes aliasing.   2048 seemed to be the minimum before which you can apply a lowpass filter.  The window size is limited by the amount which can be processed between fragments, not the amount per second.  The pi falls over above 2048 samples.  Another 1024 samples are needed because the windows have to overlap 1/2 a window at a time rather than 1 fragment at a time.  That creates a 70ms delay, which isn't terrible because the reverb needs a delay anyways.

In the wifi department, problems continued.  A switch to 5Ghz didn't change the traditional raspberry pi lockups.  At least it was a discovery that the raspberry pi 3 & 4 both support 5Ghz.  They can't do 2.4 & 5 simultaneously & they're not reliable enough for anything besides ssh.   The mane problem with a fully wired connection is those ancient RJ45 connectors always breaking.

5Ghz would be useless, since the web interface is on a cheap phone & the phone only supports 2.4Ghz.  The lion kingdom may end up dedicating a phone just for a piano GUI.

After a week of hacking, it finally had a minimally functioning web interface.  The mane challenge with a web interface has always been making the phone read the state from the board while simultaneously sending a new state from its GUI.  The latest idea was to flag every widget as write only or read only. They all start off as read only, showing the state of the board.  When the user touches a widget, it turns to write only, showing only the user input.

If a 2nd GUI is started, the latest GUI becomes the only one with the true state of the board.  Persistent settings have to be stored in the board rather than cookies because it's a pain to lose the settings every time you change browsers.

Helas, the web interface has to constantly poll to get the starting board state & the current recording state.  If the recording runs out of space & stops, the GUI can't update to show recording has stopped.  It'll just show no space remaneing & no advancement of the counter.  Lions don't expect to run out of space, but handling this would require the record button to have a read only, write only & a 3rd state for out of space.

There's never been any support for playback in a lion recording device.  It's 1 of those things lions never needed, even in their days of using walkmans for portable recording.  Maybe having it permanently connected to the instrument & easy to access will make playback useful.  It would entail showing a list of recorded files & a full player interface on the phone, while the playback would still be on the pi.  The ALSA driver would have to switch between playback & recording.

When the web interface starts polling, the wifi quickly dies while the wired connection keeps going.  Something about polling triggers a Wifi interrupt problem.  Being a stationary instrument, there's no plan to use wifi, but it is 1 more cable to manage.