Messages

Since it's a pre-built, the audiocard type must be assumed.  The default card is IQAudio.

To change that, just run ~/pi-stomp/util/change_audio_card.sh

Pick your card, then reboot.

Assuming you have a pi-Stomp v2 (aka "Core")?

If so, you have connections for up to 5 footswitches (labeled as 0 thru 4).
https://treefallsound.com/wiki/doku.php?id=customization_guide#add_pushbuttons_or_footswitches_via_the_switch_header

The extra switch(es) need to be configured as described here:
https://treefallsound.com/wiki/doku.php?id=configuration_file_guide

[Added]

New pi-Stomp v2.3.0-beta software is ready to try (as a pre-built!)

As we wait for v3 kits to deliver from manufacturing, those of you with a v2 (aka ?Core?) can benefit from all the new software features and upgrades we?ve done in the last few months.


And we?ve built it for you, so just burn the OS image and boot it!


Works with any pi-Stomp v2 (aka ?core) hardware.  v1 hardware still has an issue with the LCD to resolve.


Please try it out and let us know what you think!

More info and Download here: https://github.com/treefallsound/pi-stomp/releases/

Added

    Pre-built software installation
    Support for v3 hardware
    New LCD UI (v3 and v2 hardware)
    New access to global EQ (v3 and v2 hardware with IQAudio card)
    Patchstorage for plugin management (discovery, download, install)
    Filemanager for uploading audio files, MIDI, Impulse Response, Instruments and Amp Models (eg. NAM, Aida)
    Support for tap-tempo (v3 and v2 hardware)
    Support for most all common tasks via LCD/MOD-UI (ssh not required, v3 and v2 hardware)
    Support for Pedalboard Banks (v3 and v2 hardware)
    Support for alternate footswitch actions: longpress, multi-switch (v3 and v2 hardware)
    Support for additional plugin parameter types: log, enum, bool (v3 and v2 hardware)
    Support for assignable (multi-color) LED indicators (v3 hardware only)
    Ability to update (stash and pull) sample pedalboards via git

Changed

    Upgrade to RPi bookworm OS
    Upgrade to python 3.11.1
    Upgrade to MOD v1.13
    Upgrade Real-time Kernel to 6.1.54
    Switched to using Network Manager for network management
    Switched to using gpiozero instead of RPi.GPIO (for pi5 compatibility)
    Added hardware config file (default_config.yml) validation via schema

Yes pi-Stomp v3 is pi5 compatible.

There's just one sticky issue:
https://github.com/jgarff/rpi_ws281x/issues/528

That means that the addressable LED's used for footswitch and signal/clipping indicators, don't work with the current software build.  But as you can see at the bottom of that issue thread, a kernel solution is being worked on.  Two of us have applied an experimental version to our v3's and it does work.

So, I have no doubt we'll have 100% v3/pi5 support soon, but we're waiting for a better baked solution before rolling it into the pi-Stomp software.

pi-Stomp v1 and v2 (core) already have 100% compatibility with pi5 since they don't include addressable LED's.  We have a beta pre-build with loads of upgrades and new features available here:
https://github.com/TreeFallSound/pi-stomp/releases

1. pi5 + bookworm?

Yes.  I've had it working, but not with the real-time kernel.  The main tweaks:

sudo apt remove python3-rpi.gpio
sudo apt install python3-rpi-lgpio

Add this line to /boot/firmware/config.txt:
dtoverlay=spi0-2cs,cs0_pin=0,cs1_pin=7

If you can wait a few weeks, I might likely have a prebuilt image.

2.  The 2.8" yeah, that looks like the one we're using for pi-Stomp v3 (http://www.hiletgo.com/ProductDetail/2157216.html)
That 3.5" would require you create your own ILI9486 driver.  GPIO usage looks different.  Also, it has a different aspect ratio so you'd have to tweak pi-Stomp code to deal with that.

3.  HDMI?  You won't be able to reuse any pi-Stomp LCD code.  It's a different beast.  Where the content of an SPI display is directly written to the LCD, HDMI is meant to be a window managed desktop type display.  I suppose the pi-Stomp content could be rendered within a window/app? 

I've not experienced your issue of volume drop when using USB to power peripherals.

I experimented with a variety of small amplifier circuits to provide more drive for headphones with less sensitivity.  Even with significant power supply filtering, they all were too noisy.  If you can live with mono, you could maybe use the IQAudio onboard speaker output, but my recommendation would be to use more sensitive/higher impedance headphones and to make sure your Alsa settings are not reducing the output unintentionally - there are many stages the audio goes thru: Aux > Mixins > Mixouts > ADC > (software gain) > DAC > Headphone.  Check those using alsamixer.

My experiments with boost converters didn't yield a noise floor low enough.  I tired 5 different converters with lots of filtering.  Basically, the pi supply rail is just incredibly noisy and not a friend of any analog audio.

Regarding a fan, I've never had an overheating problem with a pi3 or pi4 which has passive heat-sinks.  pi5 does require active cooling, but the $5 fan cooler I got does the trick and doesn't add any noticeable power supply noise.

Cool project!

I believe the input impedance of the IQaudio card is less than 40k, so I would recommend a buffer regardless of the source, but yeah, your active guitar out already makes your signal low impedance.

You probably could use that ME-25 buffer.  Again, noise is always my main concern, and the CMRR and PSRR of a single transistor is rather poor compared to a very low noise op amp, but maybe worth a try.  The IQAudio inputs have an input coupling cap, but I might suggest taking the signal from TP107 anyway.

The buffer used is based on the second-to-last schematic in this article:
http://www.muzique.com/lab/buffers.htm

The parts are here:
https://treefallsound.com/wiki/doku.php?id=bill_of_materials

(search page for "buffer")

If you are powering it from the pi supply, it'll be really noisy if you're not careful.  I take the 5v rail from the pi, run it thru the 3.3v regulator and obtain the ground reference for the regulator and buffer ONLY from the IQ audio card, NOT the pi.  The regulator has a 0.1uF disk on the input and a similar disk plus a 10uF oscon on the regulator output.

That makes keeps most of the pi noise away.  A ferrite bead on the 5v line might help a tad too, but I can barely hear the difference.

Starting with a "quiet-ish" supply is helpful too.  The official Raspberry supplies are about the quietest, I've found and they yield 5.1v instead of 5.0v which helps the pi to not throttle.

There are various ways of developing LV2 plugins.  Here's a thread with some good pointers:
https://forum.mod.audio/t/lv2-101/9736/3

I don't know of any MAX LV2 plugin, but you could certainly run MAX on pi-Stomp and patch in the audio to Jack.

If you haven't already, try running:

aplay -l

and

arecord -l

To see if Alsa is seeing any audio interfaces

That would be cool.  It does seem concerning that they don't mention Linux.  If it did work with Linux, you'd think they want to tout that.  Possibly, they just don't want to officially support it.

If it's "class compliant", then theoretically, ALSA will "just work" with it.  Here's a maybe not completely up-to-date list:
https://www.alsa-project.org/main/index.php/Matrix:Main

pi-Stomp v3 hardware can run with pi5.  Most things work, but pi-Stomp v3 includes WS28x addressable LED's (for footswitch and clipping indicators) and pi5 changed how PWM on GPIO works, so controlling WS28x LED's via PWM is currently broken for pi5:

https://github.com/jgarff/rpi_ws281x/issues/528

Once that issue is fixed, we'll probably be able to standardize on pi5.

That said, I've run up to 3 NAM instances on a pi-Stomp powered with a pi4, or 1 instance with a normal set of other effects.  Works great.  So for now we're standardized on pi4.

I don't believe we'll be in full production mode by then, but might have some early kits available.  I'll let you know if it seems likely.

Your output from amidi -L looks as expected.

Your problem might not be with your DIN MIDI at all.  Because you say the control gets mapped in Mod as soon as you hit save, I'm thinking you have another controller that's continuously sending MIDI messages.  That's easy to do if you have a analog control specified in default_config.yml but you don't have anything connected to that adc_input.  In that case, it will be floating which often results in just a constant stream of MIDI messages.  I would recommend commenting-out or removing all of those and restarting with ps-restart.

If the MIDI messages from your MIDI controller still aren't heard by MOD, then I'd test your hardware with this:
sudo systemctl stop ttymidi
~/pi-stomp/utils/monitor_din_midi.py

Then tweak your controller.  Does the utility report a message (eg. print "msg 127")?  If so, your MIDI in module is working.  If not, make sure it's connected properly.

Once you get that working, start up ttymidi again and try mapping the control via MOD:
sudo systemctl restart ttymidi

Effort has been made for Bookworm (it includes some significant changes), but the changes are not complete yet.

The main effort is to convert RPi.GPIO usage to instead use gpiozero:

https://github.com/TreeFallSound/pi-stomp/commit/fa208079f4741e6e01899ef682609fcf153521d2

You'll definitely need to delete /usr/lib/python3.11/EXTERNALLY-MANAGED before building.  I'm near certain that most things will work, but I believe a few references to RPi.GPIO still exist.