Going the MODEP/RPi4/PiSOUND Route

[ElRay]

Well, I'm taking the plunge. Inspired by this post by @josefvin, I've decided to make the jump into running MODEP on a spare RPi4 I have. For now, I'm using my Presonus AudioBox iOne, but I'll most likely get a PiSOUND hat when they're back in stock. I'm in the process of backing-up the kid's old MineCraft world and downloading the PatchboxOS image, so I'll update things as I go.

I'll also tally-up costs/time, as I go.

At this point, according to US Tax law on depreciation, my cash expenditures are zero.Time-wise I'm at ≈20 mins, because I forgot linux systems can't read ExFAT drives natively, so I had to find a >8GB thumb drive that I could reformat to get the Minecraft World off the RPi4.

 

[Tree]

This is actually really cool and something I had never considered. It definitely seems like fun. Do post updates when you can!

I sometimes forget there are other uses for RPi's besides gaming and emulation

 

[ElRay]

... I sometimes forget there are other uses for RPi's besides gaming and emulation

I've been running TinyPilot as a virtual KVM for a while, and got in on the Argon40 Eon KickStarter, so that will be set-up as a in-house NAS (It's fast enough too saturate my network, so I don't need anything faster than that.). My brother also runs two RPi4s as an in-house web/database setup for development.

Regarding the gaming, the RPi4 I'm repurposing was the kids' High School Club needs a place to socialize during the pandemic MineCraft server. Peak load was 4-6 kids and never heard any complaints about lagging. The biggest issue was the dynamic DNS crap needed to work around Comcast's lack of affordable fixed IP addresses.

 

[ElRay]

OK. It's up and running in an "Out of the Box" state.

I've got the base PatchBoxOS and MODEP installed on the RPi4. It took me about 25 mins of active work, but part of that was because the install image of PatchBoxOS does not include the RPi's "SD Card Copier" and its package name is actually "piclone". You can run the system off the SD Card, but I have the Argon One M.2 case, which has a slot for an M.2 drive, and this Pi is configured to run off the SSD, so I needed to copy the default image to the SSD and reboot. And it's definitely faster running off the SSD. The rest of the time was spent kicking-off and checking in on update downloads.

The default install comes with:

• Audacity - Making/editing audio recordings. I should be able to use Jack/Patchage to route the audio out to Audacity and record what's being played
• Patchage - A modular/GUI Patch bay
• Pure Data - a visual programming language - basically make your own sysnthesizers/beats/soundscapes
• SuperCollider IDE - Another "development tool" for building systhesizers/beats/soundscapes

If had to buy everything "fresh" today the tally would be:

Raspberry Pi 4 8 GB	$75
Argon One M.2 Case	$45
512GB M.2 SSD	$50
Presonus AudioBox iOne	$120
TOTAL​	$290

... and there are ways to keep it cheaper.

I'm accessing it right now using a leftover keyboard and mouse and the HDMI portable screen I have for work. It can be set-up to run headless, with an auto-login and to run MODEP as a "startup app". You can also replicate the MOD Dwarf's and MOD Duo's browser-based interface by connecting over WiFi with a desktop, laptop or phone/tabet. It can even run it's own hotspot and you can connect to that.

No sound out yet, because I think the default routing sends sound out through the Presonus and I need to find a 1/4" headphone adapter or use Jack/Patchage to route the sound to the 3.5mm Headphone jack on the RPi.

I'll definitely be looking at getting a 2-IN/2-Out Audio Interface (The PiSOUND should be ≈$100) and a MIDI floor controller (the Beringer 12-Button + 2-Expression Pedal model is ≈$120). So, less than $250 (out of pocket) for a 12-Button, 2-Expression Pedal, Stereo-In/Stereo-out modeler system ain't too bad. If I had to buy everything new, then that would be ≈$375. Still a killer price considering the number of buttons/pedal and being 2-In/2-Out (looking for because I have a Mag+Piezo set-up).

That said, the next steps are to get a guitar hooked-up and sound out. The results of that will make the difference regarding anything previously said being of value.

 

[ElRay]

Quick update. I'm loving this. A bit ago, I "built" a pedalboard that split the signal at about 600Hz, ran the low end through an octaver to give one and two octaves lower, and then combine the signal back.

I'm also going to start over with a base RPiOS install and add the MODEP packages on top. The Bullseye builds offer a few improvements for RPi4s, most notably when it comes to overclocking. I haven't really built anything that causes noticeable under-runs, but I might as well try it before I need it.

 

[ElRay]

OK. I have officially gone off the deep end:


The latest version of Raspberry piOS came out, which has better support for overclocking the Pi4, and gcc10 has better support for auto-vectorization, and MODEP is now two releases behind the core MOD Duo source, and the newer versions of the MOD Duo code supports playing audio & MIDI files, so I decided I was going to start with a fresh, current 64-bit OS and install the latest MOD Duo stuff on top.

Then I thought, "Wait a minute, if gcc supports vectorization better, I might as well compile everything from source!" Things were going great until I encountered JACK (the audio routing software used). This turned out to be a bi-double-t-ch, with dependencies that have dependencies and non-obvious stuff like "sndfile" capability is provided by ALSA, but on linux you need to install the OSS version of libsounda, but the OSS version requires the non-OSS versions to be built first.

So, I drank the Gentoo Kool-Aid and I'm going to build the whole OS, from source, with optimized settings for what I need, and exclude the cruft I don't.

And then I'll grab the latest MOD Duo code and compile that from scratch.

 

[rexbinary]

 

[cmpxchg]

I looked at some of the source for this when you posted this thread. The core audio bits seemed to make decent use of SIMD intrinsics, so autovectorization won't do anything there. (to be fair, autovectorization almost never does anything outside of toy programs to demonstrate wins from autovectorization.)

 

[ElRay]

Often true. I tried Gentoo when it was new, got into an --funrollloops argument and haven't looked at it for almost 20-years. So far it has gone relatively smoothly. Much more smoothly than building JACK from scratch.

I think 90% of the problems are from folks doing the equivalent of counting grains of sugar instead of just measuring 1/4-cup. Then you've got the folks that will argue how many grains of white sugar mixed with how many grains of brown sugar.

I just want to use the best all-around compiler flags, make sure everything is compiled 64-bit natively and not for the broad aarch64 class and set appropriate "-Idont-need-this-dont-install-it-ever" flags, so that nothing is pulling clock-cycles away from the amp/pedal/cab sims. I MIGHT (and that's only if I see too many XRUNS) re-compile the MOD Duo code with higher optimization and faster, but less accurate floats, but I'll have to hear audible drop-outs and glitches before I get to that realm.

 

[cmpxchg]

I just want to use the best all-around compiler flags, make sure everything is compiled 64-bit natively and not for the broad aarch64 class and set appropriate "-Idont-need-this-dont-install-it-ever" flags, so that nothing is pulling clock-cycles away from the amp/pedal/cab sims. I MIGHT (and that's only if I see too many XRUNS) re-compile the MOD Duo code with higher optimization and faster, but less accurate floats, but I'll have to hear audible drop-outs and glitches before I get to that realm.

oh no, don't use -ffast-math, everybody hates ffast-math. also if Pi 4 is A72-based, then it's only ARMv8, not 8.1/8.2, and there are no worthwhile compiler flags to add on top of basic aarch64 (been a while since I looked at gcc, but everyone else is assuming ARMv8 includes the basic A53/A57 stuff, which IIRC is the same in A72).

some of the pisound kernel drivers need work, maybe I'll buy one of these sometime and send some patches

 

[ElRay]

I looked at some of the source for this when you posted this thread. The core audio bits seemed to make decent use of SIMD intrinsics, so autovectorization won't do anything there. (to be fair, autovectorization almost never does anything outside of toy programs to demonstrate wins from autovectorization.)

True. The main issue is the binaries from a regular distro are compiled to run on any of the aarch64 processors and flags like -mtune, -ftree-vectorize & -fomit-frame-pointer will make a difference with the Cortex-A72 in the Pi4 (mostly because that will enable additional registers to be used).

There are other core libs (alsa/opus/libsndfile/libsamplerate) and also (assumingly) JACK that will benefit from better byte alignment and use of registers, even if the NEON/SIMD auto-vectorization won't do much. But, that's also one of the features of gcc10: what auto-vectorization there is, is better.

I've been playing with the Blokas MODEP stuff for a while. We'll see how the mainline MOD Duo code does on a only-what's-essential Pi4. I'm even thinking about totally pulling all the desktop/vnc stuff and accessing it purely by the MOD-UI web server and ssh. Not a good idea if I'm gigging, but perfectly fine for home use.

Yes, this has transitioned from the "lets get this up and running as quickly as possible" to the realm of "Let's turn three Model-T bodies and an old hearse into the Munster Koach" project. I fully admit that if Blokas had the PiSOUND hats back in stock sooner, I likely would have put everything into the acrylic box and left everything vanilla.

End-to-end time will be longer with Gentoo, but it will be less hands-on/active-time because I can kick off an emerge before I go to sleep, and it will be ready before I can get back too it. Trying to build the MOD code from a Ubuntu-Lite base was a lot more hands-on and required a lot more interaction.

So far, the only head-scratcher was how to follow the build steps when they're written from the perspective of starting with a "live" microSD or bootstrap in-place over the default microSD, but I want to install it on the external M.2 SSD

 

[ElRay]

oh no, don't use -ffast-math, everybody hates ffast-math. also if Pi 4 is A72-based, then it's only ARMv8, not 8.1/8.2, and there are no worthwhile compiler flags to add on top of basic aarch64 (been a while since I looked at gcc, but everyone else is assuming ARMv8 includes the basic A53/A57 stuff, which IIRC is the same in A72).

-O3, -Ofast, -ffast-math, etc.

… is only if I'm having issues with XRUNS.

Before diving into this, I spent time digging into what gcc10 supports with the different aarch64 chips. Best set of flags I could dig-up, specifically for the Pi4, are:

"-march=native -mcpu=native -mtune=native -pipe -O2 -ftree-vectorize -fomit-frame-pointer"

The last two allow for better use of registers. I was on the fence about '-mcmodel=tiny', because it has the effect of loading static symbols in one instruction instead of two, but I left it out at the end. I can't use 'distcc' with the '…=native' flags, but I have no intention to. I could always flip them to '…=cortex-a72', if necessary. Digging this all up sucked a bit because there are a lot of pages showing "Updated 9 days ago", but the content is from 2017.

I will revisit this after gcc11.3 comes out in the next week or so and I get a snapshot of the system after it's built.

some of the pisound kernel drivers need work, maybe I'll buy one of these sometime and send some patches

That would be great. We'll see what happens between now and when they're back in stock. For me, the form factor for stereo-in/out and MIDI-in/out is the driving factor. Right now, things look odd with the Pi4, setting in its case, on top of my PreSonus iOne, that is about 50% bigger.

 

[cmpxchg]

Before diving into this, I spent time digging into what gcc10 supports with the different aarch64 chips. Best I could determine was:

"-march=native -mcpu=native -mtune=native -pipe -O2 -ftree-vectorize -fomit-frame-pointer"

I was on the fence about '-mcmodel=tiny', but left it out at the end. I can't use 'distcc' with these flags, but I have no intention to.

you could try -mcpu=cortex-a72, but in many years of doing this, I've never seen a -mtune value measurably change a non-trivial program's performance (unless you're talking about a vector math library or something like that). -mcmodel=tiny is not a good idea.

 

[ElRay]

you could try -mcpu=cortex-a72

I tend to stick w/ native, unless I know there's a compiler issue where '=native' produces worse code (like 'native' compilation on pentiums was worse than the generic 'i86' setting -- ghad, am I dating myself that bad?), or I intend to move the code. This is 'hot rodded', 'build in place, leave in place' code. It ain't going anywhere except to a back-up when complete.

-mcmodel=tiny is not a good idea.

That was a new one for me too. The justification is that supposedly gcc fails gracefully when the conditions can't be met, and it cuts down on instructions for static data -- at least for aarch64, can't say anything about any other processor

The real question comes down to how much of a benefit you will see by making static data more easily accessible (my expectation is that there's not enough const/static definitions to see any benefit), and I'm not sure the if compiler would handle it gracefully when it can't satisfy the requirement.

I'll get this running and then it might be worth benchmarking some of these options when I can afford a weekend of compile time.

 

[ElRay]

Gentoo (at least on 64-bit Raspberry Pi/ARM64) is a soup sandwich.

Thank you for coming to my TED talk.​

 

[LostTheTone]

Oh sweet - I never even thought about this kind of approach.

Does it have a decent cab sim or IR loader?

 

[Veldar]

Never thought I'd see pisound on SSO,
What's the in out latency like?

 

[ElRay]

The Pisound (I can never get the inTerCaps straight with that one) has been out of stock since I discovered the whole MODEP project. Using headphones connected to the monitor jack on a 2016, plain old USB2, PreSonus AudioBox iOne, I didn't notice any appreciable lag. Also, it's an 8GB Pi4 running off a USB3 SSD, not the microSD. I could have easily stuck with this, as long as I had a phone/tablet/computer to hit the built-in webserver to change presets.

The two big draws of the Pisound are the I/O (stereo In/Out & MIDI In/Out) and form-factor. After the Pisound is back in stock, I'm either going to turn the whole thing into a stomp-box (aluminum "pedal" case + true-bypass circuit) or a desktop "SuperBean" (7" touchscreen + case).

If the Pisound was in stock sooner, I likely would have left things the way they were; however, many "I might as well …"s struck:

• The version of the MOD Devices code that MODEP is using is two releases behind
• The MODEP version has no "file" support, so no MIDI-file/wav/mp3 playback or IR support*, but the past two MOD Devices versions have file support.
• So, I might as well: Work on building the latest MOD Devices code
• So, I might as well: Switch to more recent OS and compilers that have better RPi4 overclocking and "math" support
• So, I might as well: Switch to Gentoo, so I can avoid anything unnecessary that would consume clock-cycles and make sure everything is built/tuned for the best native performance.

Hopefully I'll have the software back running before the Pisounds are back in stock.

There's also other Pi-Based options that should work with Pisound/PatchBox OS. The ones I looked into were: GuitarTrix, Rakarrack and GuitarML/NeuralPi. The last is more "Kemper" like (you need recordings of the raw input and processed output of what you want to model), while the first two are more Helix/AxeFX-like. I went the MOD Devices/MODEP route because of the stereo input and webserver-based pedalboard builder.

If this works well-enough, then next step is to build another and hook it up to a set of MIDI "Organ Footpedals" and replicate one of those "Taurus Bass Pedal" rigs.




*There are a number of parametric EQ and cab-sim modules in the MODEP port, so you can likely get something close enough. There's even a "Tube Warmth" pedal (basically a unity-gain pre-amp), so if you wanted a super-clean, minimal pedal-board, you could run that into a cabsim.

 

[LostTheTone]

Ok, I have been doing some reading, and I'm kinda thinking I am going to buy in. I need a project over the summer, and I have always wanted to get into Pi world, so screw it why not? I do happen to have a little Mooer Radar to do cab duties anyway, so it's all good. Also, I am notoriously cheap when it comes to guitar hardware 👍

I tend to agree with you that ModEP is the right place to start - Reading some of the other documentation and seeing that you NEED a laptop on Linux to control it which is horrible UX. Being able to use anything with a web browser is way way way smarter.

Do you happen to know if the Pi handles less good audio interfaces well? I have a cheap Behringer one in a drawer that would be perfect but it doesn't even have good drivers on Windows.

 

[ElRay]

Right now, my experience is limited to the AudioBox One. I have a used PreSonus 26c coming (needed for a different project, but its 2xIn will be used until I can get a PiSOUND.

I think I have the Gentoo bootstrap licked. I will likely make an image of the drive available after I'd got it running. That said, I'd definitely start with the PatchBoxOS before deciding to drink the Gentoo, compile everything from scratch, Kool-Aid.