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

[Marc]

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 :

the error message :

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

Thank you - Marc

[Giedrius]

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.

[Marc]

Thank you very much Giedrius !
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)

[hlnorris]

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

[sone]

I’ve copied my posting to a better thread:

MODEP and Raspbery Pi 4

Hi, with the newest Patchbox image and a new RPI4 I do not get any USB port, mouse & keyboard to work. If I do “sudo rpi-update” the USB ports and USB devices are working fine with the updated kernel 5.4.51-v7l+. I’ll get the Pisound in a few days and because the setup via ssh is working I’m looking foreward to use everything as intended but of course working USB ports are desired. I had no success to use a different compiled kernel - via this description: https://madskjeldgaard.dk/posts/ra…

[fpa]

@Giedrius

@fpa

the system as often unexpective bug that force me to unplung the power; do you know something about that

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.

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?

[Giedrius]

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

[fpa]

patch@patchbox:~ $ journalctl --list-boots
-19 31676eea627a494f9b16bac144db3877 Thu 2019-02-14 10:12:00 GMT—Sat 2020-05-16
-18 07b52baf24db4039947200edb5df5eb2 Sat 2020-05-16 18:39:21 BST—Sat 2020-06-13
-17 3e3ea7d3796544b6811a6aec26e55741 Sat 2020-06-13 16:31:15 BST—Sat 2020-06-13
-16 e46e2c8309e74ffc97395cde3cdaf4e0 Sat 2020-06-13 16:32:23 BST—Sun 2020-06-14
-15 5763ea23dd1043448f570896b80f8a93 Sun 2020-06-14 09:29:32 BST—Sun 2020-06-14
-14 71006d0b999743179e2a54fdcc0219e3 Sun 2020-06-14 09:36:31 BST—Sun 2020-06-14
-13 d5fd7da1512748488615c5ae6b8a5061 Sun 2020-06-14 09:39:04 BST—Sun 2020-06-14
-12 1dbde5374df248a08826e74bb7976b87 Sun 2020-06-14 15:29:54 BST—Sun 2020-06-14
-11 e1af2dc00fe948ad9adeb9cfc7d581e7 Sun 2020-06-14 15:59:13 BST—Sun 2020-06-14
-10 d16bd3c930074b938cd6ddf3ef47e3f6 Sun 2020-06-14 16:07:51 BST—Sun 2020-06-14
-9 95b7dd73a7d44085aae980659825463f Sun 2020-06-14 17:35:43 BST—Sun 2020-06-14
-8 a69e9e83e88c441db062b6b53bae9f04 Sun 2020-06-14 17:36:59 BST—Sun 2020-06-14
-7 c715f8385e4f40cc9890b6ea8ae5821c Sun 2020-06-14 17:42:21 BST—Sat 2020-10-31
-6 fa809aa984cb4eca92f350a50de0798b Sat 2020-10-31 15:26:36 GMT—Sat 2020-10-31
-5 33fcee0b9a014f93b9524e3317ee5b39 Sat 2020-10-31 21:51:32 GMT—Sun 2020-11-01
-4 5f5e8ce0e20b425f91d11e9ea713da1a Sun 2020-11-01 14:05:55 GMT—Sun 2020-11-01
-3 1a93b287b037488aacfa66445ad98af1 Sun 2020-11-01 16:28:31 GMT—Sun 2020-11-01
-2 5b840024ec1c416eb4fcf6d9eb1a9bfe Sun 2020-11-01 18:04:46 GMT—Sun 2020-11-08
-1 a7f23c807010468c8fb2c143492ade09 Sun 2020-11-08 15:03:55 GMT—Wed 2020-11-11
0 8c8564f2e0084349a303aa3c633c65d6 Wed 2020-11-11 10:09:33 GMT—Wed 2020-11-11
lines 1-20/20 (END)

Blockquote

[fpa]

This is the 2 new logs i have donecrash2.log (257.0 KB) crash3.log (344.5 KB) ; i dont know realy what to do with:

journalctl --list-boots

[Giedrius]

When roughly did the issue occur?

[fpa]

8 november, twice

[Giedrius]

What happened exactly when it occurred? So far it looks like there’s some Jack backend errors, but I don’t see the system locking up.

[fpa]

I was on modep in local host, and the screen froze and no sound was generated

[fpa]

another day on orac, a shrill sound was emitted, with no way to regain control

[Giedrius]

Please provide logs using:

• -b -3
• -b -4
• -b -5

As the Raspberry Pi’s system clock gets synchronized to network time only some time after boot, it’s a bit difficult to follow the timeline, so just to be safe, earlier logs might help.

[fpa]

the problem just happened when i was looking at youtube video… these are the log , i give youcrash11.log (1.3 MB) crash21.log (88.3 KB) crash31.log (257.0 KB)

[fpa]

here are the log you asked mecrash4.log (344.5 KB) crash5.log (550.2 KB) crash6.log (82.5 KB)

[fpa]

do you think that

Nov 11 11:18:40 patchbox jackdrc[436]: JackAudioDriver::ProcessGraphAsyncMaster: Process error

could be the reason?

[Giedrius]

This indicates that Jack backend, responsible for audio, started to have some issues, most likely buffer underruns. This can happen if the system is overloaded. What are the Jack backend settings you’re using? Try increasing the parameter values for more stability.