Patchbox OS image 2020-03-14 (and MODEP)

Thanks @Giedrius and @tob_har

“systemctl enable jack” did the trick.

I was expecting that selecting puredata in modules and then selecting a patch to launch would make it so that this patch was loaded on reboot, but that is not happening. I still need to run patchbox or use the app, or I guess another option is to copy the patch to a thumb drive and click once to load it.

Yes, it should open automatically, there was a bug which I just fixed - patchbox-init.service was missing. Run patchbox update to get this resolved. :slight_smile: Thank you for reporting it.

Problems solved! After updating, my selected patch loads automatically after reboot, and jack is running, too.

2 Likes

Hello,

From my side, I#d like to say I also experienced the bluetooth problem mentioned by @Giedrius and, before taking the drastic decision of updating the kernel, I ran sudo apt-get update, after verifying that patchbox update was already at the latest state. In my case, there were a bunch of libraries that got updated and, similarly to @mistymountainblow, libbluetooth3 was among them (though not bluez). That seem to have done the trick for me: no drops so far. I get now:

patch@patchbox:~ $ apt-cache policy libbluetooth3
libbluetooth3:
  Installed: 5.50-1.2~deb10u1+rpt1
  Candidate: 5.50-1.2~deb10u1+rpt1
  Version table:
 *** 5.50-1.2~deb10u1+rpt1 500
        500 http://archive.raspberrypi.org/debian buster/main armhf Packages
        100 /var/lib/dpkg/status
     5.50-1.2~deb10u1 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
1 Like

Hi, I have installed the new update but had several errors.
Now I cant open patchbox-config now.
As a version I get:
Linux patchbox 4.14.91-rt49-v7+ #1 SMP PREEMPT RT Tue Feb 19 15:51:26 EET 2019 armv7l

patch@patchbox:~ $ sudo patchbox-config
Traceback (most recent call last):
  File "/usr/local/patchbox-cli/patchbox/cli.py", line 2, in <module>
from patchbox.utils import PatchboxHomeGroup, PatchboxChoice, do_group_menu
  File "/usr/local/patchbox-cli/patchbox/utils.py", line 10, in <module>
from dotenv import load_dotenv
ImportError: No module named dotenv
patch@patchbox:~ $

Edit:
I can access the Pi through startx though, so I see the graphical env, hmmm any ideas what I could do? Reinstall Patchbox?

Hey, see my latest reply this thread: No module submenu?

Oh thanks for the quick answer! I guess then I can simply Download the new Image, and make a fresh install? Thanks a lot!

Yes, you have to flash the 2020-03-14 version image.

Hi, i used to use th last patchbox os with pisound board on rpi3b+, and since i burn a new sd with the new image, the system as often unexpective bug that force me to unplung the power; do you know something about that? (i hadn’t that kinde of probleme with the last version, so i charged a old version of patchboxos but when i updated the system to load orac bridge, patchbox parameters in ssh is not availaible…)

We didn’t see anything like that, we’ll need more information to know what’s going on.

You’ll have to enable persistent logging, so after the system crashes, the logs are still available:

sudo nano /etc/systemd/journald.conf

Edit the file, so that #Storage=auto line looks like this:

Storage=persistent

Hit Ctrl+X, to exit, press Y to confirm saving your changes.

Then restart the system (sudo reboot), and once the crash occurs, on the very next boot after the crash occurred, you can access the log of that session by running:

journalctl -b 1

It can be saved to a file by doing:

journalctl -b 1 > crash.log

Then you may share the crash log here for us to investigate what’s going on.

thank you, i juste made it, so… wait and see!

Hi,
What a great job you have done here ! :+1:
Have build a Modep pedal with a Pi 3B + Pisound + the case + the the last Patchbox image => it works fine on the first start… - Thank you for all !

Just find this issue while loading a pedalboard : as saving a pedalwork, it is ok, no error message - but when loading it, Modep refuse and display an error => can’t load the pedalboard because plugin missing
My Patchbox is 100% stock, no change

If the pedalboard is empty (no modification on the defalt empty pedalboard), error is still the same
Only the 4 default pedalboard can be loaded, not a modified and saved one

Thank you - Marc

A post was split to a new topic: MODEP and switching to next and previous pedalboard using Pisound’s button

Here are some screenshots of the “pedalboard” issue :

try to save the pedalboard (empty, no plugin) :

the pedalboard does not display as the default ones :

03

04

the error message :

05

the Pi OS and Modep is 100% stock from the downloaded image from the website, no modification - Raspi 3B + Pisound

Thank you - Marc

Ok, I tried the same - saving an empty pedalboard, and got the same errors as you do. But at least saving and loading a pedalboard that does contain some plugins seems to work fine. :slight_smile:

Thank you very much Giedrius ! :+1:
yes, it works fine when saving a real pedalboard, great !
Love this Pisound / Modep so much, I’ve done a building tutorial : https://fr.audiofanzine.com/autre-bundle-d-effet-ou-multieffet/blokas/modep/forums/t.711701,tuto-construction-modep-pisound-de-a-a-z.html
(in French, sorry)

2 Likes

Is there still an issue with the Pimoni Fan Shim and the Pisound. It seems like following the instructions on then Pimoni page " a script to install a daemon (a service that runs in the background) that runs the fan in automatic mode, triggering it on or off when the CPU reaches a threshold temperature, with a manual override via the tactile switch." should be able to get around this. Is this what folks have been using? TIA

I’ve copied my posting to a better thread:

it’s been a while since I last used my py, and recently I encountered the same problem as before, so I looked at the logs as you told me, but I don’t understand why, I have the impression that there is no recent eventcrash.log (1.3 MB) .
Can you tell me what’s your point of view please?

Hi, this log seems to show a normal session with proper shutdown. Looks like the value for -b should have been -1, not 1.

Try producing logs of -b -1, -b -2, and inspect the output of this command to try and find the log containing the crash:

journalctl --list-boots