Piano signal processor

Since the headphone connector is on the left, the right cable is getting more strain.  It's always breaking in the knot.  The decision was made to swap the playback channels in software & wear the phones backwards to spread the strain.   It's unlikely anyone else in the world has resorted to such drastic action to keep 38 year old phones alive.

Also tweeked the reverb again.  It seems to cut completely off when reverb_level2 goes below -50.   It could be a quantization problem with float32. 

The browser app has been just good enough, but it's awful.  Phone browsers just can't do polling in javascript nearly as fast as commodore 64 basic.  The effort to convert it to an app was stalled by the prospects of having to commute again & the  longevity estimates of this project.  There's no way to practice when commuting & that could happen in less than a year.

With retirement rapidly approaching, lions have pondered the future of the CP33.  It's most likely going to stay the mane instrument as before & lions will never own an accoustic piano, but there's a nonzero chance it'll get replaced by an acoustic piano in less future time than it's past lifetime.  It would be a waste to rewrite the signal processor if it only has 5 years to go.

Another full day rewriting most of the raspberry pi code finally pushed it to the finish line.

It's still very minimal, but it's super fast.  It turned out libusb_init leaks memory if it's repeatedly called.  The app more proactively disables user input until it gets a packet from the instrument containing the instrument's state.  If the instrument is rebooted after the app detects it, it'll overwrite the instrument's initial state.  This shouldn't be a problem, since rebooting the instrument shouldn't undo anything the app previously set.
The lion kingdom never used the reverb again, after the early days discovering it made it impossible to hear nuances. 

There were ideas to require a confirm checkbox to make the update buttons do anything.  There's also room for + - buttons for the metronome.

The address text is arguably useless.  It could be hard coded.

Noted the app isn't showing the phone's time bar.  They all seem to require a title bar before before they show the time bar, otherwise they just have a black bar on top.  The truckcam app managed to show the time bar without a title bar.

There was a guy who ported a DX7 emulator to a bare metal raspberry pi.  Why the port was on bare metal is beyond lions.  Maybe the pi wasn't fast enough to do all the processing.  The process does seem to involve porting a VST plugin from source.  There's no windows emulator for the pi which can run a headless VST plugin.

The most likely outcome for a DX7, K3, & piano emulator is going to be a dedicated windows confuser.

Desperately needed a phone stand.  The phone was all over the place.

To run it as a daemon, it needed to truly detect when the soundcard & the instrument were unplugged, then stop the signal processing when the instrument was unplugged.  Detecting when ALSA is unplugged requires a complicated polling routine.

snd_pcm_status_t *status;
snd_pcm_status_malloc(&status);
snd_pcm_status(dsp_out, status);
int state = snd_pcm_status_get_state(status);
snd_pcm_status_free(status);

if(state == 0)
{

// disconnected

}

Detecting a USB disconnect requires testing for a LIBUSB_TRANSFER_STALL.

The next problem was buffer overruns when recording, despite using O_DIRECT.  The activity LED tended to get stuck on.  

The raspberry pi uses a swap space on the SD card which must be disabled.  

root@piano:/root% swapon --show

NAME      TYPE SIZE USED PRIO
/var/swap file 100M   0B   -2

The easiest solution is renaming /usr/sbin/swapon to /usr/sbin/swapon.bak

The raspberry pi has enough RAM to record 3 hours of audio in RAM, but to simplify the pointer math, the FIFO can be expanded to just 30 minutes.  The worst case would be to record to RAM & write it after the user stops, but it wouldn't be resistant to power outages.  

After recording for 51 minutes,

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND

4     0  1790     1  -2   - 772096 469844 hrtime Sl  ?         30:29 ./piano

It filled the entire allocated buffer because it's a ring buffer, but it didn't have a single overrun.  It could be optimized by capturing the longest fill size, but that would be wasting the raspberry pi's 4GB of RAM.  The LED only seemed to stay on for 1 minute at most.

Finally ended up with a satisfying GUI that could control line input for monitoring a microphone.  64 bit file support is still an issue with the raspberry pi's because they're 32 bit.  It may never be tested with 64 bit file support because lions have never played more than 2 hours at a time without stopping.  

It detects disconnection & connection of the instrument but not disconnection of ALSA.  The soundcard just doesn't get disconnected.  Recovery after the loss of any peripheral would be best done by restarting the program inside a loop, but that would make it hard to debug.  If it restarted the program during a disconnect, it would stop recording.

The final solution with the web interface was to have it read the board state once when it starts, then ignore the board state in favor of user input thereafter.  It continuously polls to get the state of the recording.  

If another GUI starts or if the board reboots, the 1st GUI just won't show any valid board state.  There's no plan to have the board reboot on its own.  The board could send a flag requiring the GUI to reset, but it's a bit overcomplicated.

There was some desire to have a VU meter.  The digital stage in the CP33 doesn't have variable volume.  It's calibrated for an average playing volume & just clips when it's too loud.  A VU meter would have no purpose & take up space.  

The thought isn't lost of continuing to expand the signal processor to capture MIDI & generate human readable notation.  It could pass through MIDI to a phone or it could use its own monitor on HDMI.  All gadgets have been evolving to a dumb web based GUI with all the computation on a single board confuser.