Buy me a coffee 404

[pjwiseman]

The buy me a coffee link returns 404. (https://www.buymeacoffee.com/jajito)

So instead, I place my thanks in a comment against your video.

[jajito]

Hi Peter, thanks, I hope it will be useful, and let me know how you improve it!.

[pjwiseman]

1. Upgrade to Python3
2. Add comments (things I discovered as I work through the code)
3. Fix exceptions (as many as I can). E.g. race condition on exit fixed.
4. Additional guidance to explain some elements of the user interface among set-up. (E.g. Mackie, enable remote daw)
5. Possibly some install options. (Simply because I haven't installed some things, e.g. samba, as l will use scp)
6. Possibly some testing options. As I only get in front of an x32 once a month to test.
7. Possibly a logging option (which I can analyse after a live session)
8. Fix any issues I find (for example, stop didn't kill the recording, resulting in multiple recordings in parallel). Possibly a fault I introduced moving to python3.
9. Code refactoring/renaming to English.

PS. I like your code. Clear separation into functions. And... I have what I needed, a live capture for training purposes using a Raspberry PI 4 with no screen. Powered by battery to avoid power hum issues.

Sadly, I have "underrun" which I'll need to troubleshoot further. I'm hoping it is just a user stick that is below spec. Formatted to xfs as per your guidance. But playback seems ok, so it seems mild.

Peter (peter.wiseman@gmail.com)

[jajito]

Hi Peter.
If you consider the amount of data to be recorded in a 32 channel recording.. Yo have to use the fastest stick.
But with a Raspberry Pi 4 and XFS format, it works flawless. Remember to feed the RPI 4 well, 3 amps minimum, and good cooling, as it gets very hot. Other format than XFS will not work or an older RPI.
The recording stops if you stop it in the program or kill it afterwards, but if you get out of the program without stoping the recording or don't kill the process afterwards, the recording will continue, that's how SOX works, possibly the underrun is because you were recording 64 or 98 tracks in several paralell recordings...
Feel free to improve "the creature".

[pjwiseman]

Thanks. I realised overnight that I think I only saw the underruns in the second and definitely third parallel recording. Yes, those recordings are likely due to me killing the app without killing sox. I forgot about needing rec+stop to stop. It was logging unable to kill due to play_recorded_process being empty, so that may have helped my confusion. I'll troubleshoot the log further, make sure it highlights the rec+stop requirement, and determine why that variavle is empty. I have a 14GB, 1hr50m, 16 track recording on a 32GB stick, which is 2.3MB/s writes. I can do a sustained dd copy of that file with bs=1000000 from/to the same stick at 6MB/s, 42min. My battery is capable of 3A. I'll need to monitor heat and CPU utilisation. I have a flirc case which should do a good job as a heat sink. I discovered that the X32 is configured at 44100 sampling rate and sox is defaulting to 48000. I'll change the X32 sampling rate. When live, I'm connecting to the PI using JuiceSSH from an Android phone using MOSS to prevent disconnection loss. I've pushed my work in progress to my github repo.