Request: start-to-finish walkthrough, with expected steps throughout

[circumlocutory]

I spent Thursday and Friday of last week trying to get this running on my Pi 3B v1.2, using an Akai MPKmini MkII as the controller (the very same as the one in your video, I think?).

I can get sounds to work when running headlesspi.py in Terminal. However, it opens with an error related to Sine Wave.

For reasons unclear to me (sorry if it's simply down to me not understanding some fundamentals -- tell me!), the script does not appear to run on boot, even after adding it to crontab.

I can use K5 (encoder on Akai) to move through various sounds, but cannot get a sense of whether the bank and patch change options are working (which I hooked up to Pad 8, 4, and 3). It might be useful to have Terminal spit out a print() message when changing, with some info. The pad controls appear totally erratic at present.

Anyway, please let me know how to help, and if you can, gimme some pointers on why I can't get this to work as hoped :)

[albedozero]

Sorry for the troubles! The message about Sine Wave is more of a warning than an error - it refers to the fact that drum preset 128:001 in the VintageDreamsWaves-v2.sf2 soundfont expects a ROM sample that used to be available on the old Sound Blaster cards, but of course doesn't exist on the Pi - I would fix it but the author's license doesn't allow modification.

If you're running the install script to set everything up (curl https://geekfunklabs.com/squishbox | bash) you shouldn't have to set up a cron job or edit rc.local to have headlesspi run on startup - the install script creates a systemd service for you that should be much more reliable than either of those methods. In fact, if you also add headlesspi.py to crontab you might be running two separate instances of the synth, which could cause some of your issues. Are you never seeing the 5 blinks from the green ACT led to indicate readiness after booting up? It does take 15-30 seconds to boot. You can check on the status of the startup service by logging in and typing at the command line

sudo systemctl status squishbox.service

You should get a blink from the Pi's green ACT led when changing patches or solid green when loading the next bank. You can also run the script with the option --interactive to get more information about errors - I'll add some print statements about patch/bank changes as well.

I did originally do set this up with an MPK mini mkII, and one annoyance I remember is that the drum pads only send on MIDI channel 10, while the knobs can be assigned to whatever channel, but are channel 1 by default. If you set CTRLS_MIDI_CHANNEL = 10, do the pads work to change patches for you? Make sure they're sending momentary as opposed to toggling CC values.

[circumlocutory]

Firstly, thanks for getting back to me :)

1. Okay, interesting! So, in this image Terminal shows it as running, but there is no audio until i run it myself. Any ideas?

2. The pads send on 10? How bizarre, though I get the historical reason. Okay I'll try changing that now and see what happens. Update: that did not fix it, but in the below image, I confirmed that the controller is using channel 1, so i reverted headlesspi back to 1, and lo and behold, it's working! Your momentary vs toggle note was the answer (they were still set to toggle). That said, I was getting erratic change behavior last week enabling PROG CHANGE and using that. So... maybe that is doing something? I added some of my own print() commands while trying to debug this on Friday, and they are now working! It says 'patch incremented' when, you guessed it, the patch is incremented.

I am getting pretty solid crashing behavior, but I think it's my pi being sad. It happens pretty reliably when the pi reaches 60 degrees. I need to solve that somehow...

[circumlocutory]

Okay, this is dumb... It appears to run headlesspi just fine if i don't have a monitor connected. I know how dumb that sounds to read, but I didn't think it would matter. 🤦‍♂️

[albedozero]

I've had this exact same problem, and it turned out to be my power supply! HDMI draws a lot of power, more so on the newer Pis, and the 2-amp power supply I had just couldn't quite make it if I had a monitor connected.

PROG CHANGE is that PC row on the pads, which is yet another type of MIDI message called program change, which tells the synthesizer to switch to that preset number in the current soundfont. I know this is confusing - soundfont files have presets organized into banks, numbered XXX:YYY (XXX=bank, YYY=preset), while our code allows you to switch between patches in different bank files, where a patch can activate any preset(s) you want from any number of soundfonts at once (memory allowing).

[circumlocutory]

Fascinating! I never would have expected the power supply to be the issue...

Ahh, so prog change is functional in this setup, but just not documented - is that correct?

Thanks for all the help! Please feel free to close this issue if you're happy :)

[albedozero]

Correct! Program changes will be received by Fluidsynth, but this might produce some confusing behavior. For example, sending PC 3 on MIDI channel 1 while on the second patch in bank1.yaml - 'Rhodes' will not select the third patch, but will select the third preset in 'FluidR3_GM.sf2' - the soundfont assigned to channel 1 - which is 'Honky Tonk Piano'. This can sort of be useful if you have a controller with program change +/- buttons, so you can step through all the presets in a soundfont, but this isn't really the software's intended use - it's meant to let you set up the specific sounds/effects you want to perform with, rather than be stuck with the presets as they're ordered in a single soundfont. It would be nice to be able to bind program change messages to switching patches, but Fluidsynth's public API doesn't expose anything you can really use for this (AFAIK), and control changes are more available on most controllers anyway.