-
Channel swapping
04/07/2024 at 22:32 • 0 commentsSince 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.
-
Android tweek
02/22/2024 at 07:39 • 0 comments -
Android rewrite
02/19/2024 at 19:24 • 0 commentsThe 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.
-
Dexed on raspberry pi
11/28/2023 at 18:45 • 0 commentsThere 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.
-
Phone stand
11/13/2021 at 07:44 • 0 commentsDesperately needed a phone stand. The phone was all over the place.
-
True hotplug, buffer overruns
04/06/2021 at 06:05 • 0 commentsTo 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.
-
Handling Device Disconnects
03/23/2021 at 18:55 • 0 commentsFinally 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.
-
Web interface
03/21/2021 at 05:11 • 0 commentsAfter 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.