Pico on Orac: Just Plug it in?

Mark has made a number of ORAC videos, some general, some specific, e.g. “Orac 2.0 for Raspberry Pi” should be interesting:

MEC should come with the pisound ORAC module, but the service has to be configured to auto-start manually once (it’s explained in the video). Unless the Pico turns out to be too power hungry, you should be able to directly plug the Pico into the Raspberry Pi 4. Would be worth a try. (I still have a Pi3 with pisound with an Alpha which worked)

P.S.: You could also experiment with the power limit for the USB ports: https://www.raspberrypi.org/forums/viewtopic.php?p=594183#p594183

hey NothanUmber thanks for such a quick reply…
So maybe it might even work with my Tau? Maybe without extra power… since they both have their own power supplies… Yea! maybe. we’ll see.

Live long & prosper -Tefman

Yes, I would assume so. :slight_smile: You just have to use the right mec config file.

P.S.: I can remember I even tried Pico also. Had to set max_usb_current=1 in the /boot/config.txt for Pi3, then it provided enough power. Perhaps not needed for Pi4 anymore, don’t know.

2 Likes

So I tried my Pico on an rpi4 with orac… nothing. the remote is working thru Pd patch on my mac. Can change and control pre-sets but no Pico.
Bummer. Will it not work with the remote patch on? tried a1 poly plus the sampler… what I am I missing? Midi works great. Will try the power mod to usb maybe tomorrow. Eigenists, any thoughts?

id need to know how you have set it up precisely, and also see the logs.

which MEC config are you using?
you will need to ensure it is using the one that has the pico enabled… by default it is not.

Thanks sooo much Mark:

Hardware= Rpi 4 4GB, apple keyboard, running console.
Pisound stuff from pisound config.
button v1.11
hardware 1.1
server 1.03
firmware 1.03
serial ps-1wktpkc

Attached is part of my full syslog:

There is a usb failure quoted below?

Jul 26 01:38:47 patchbox mtp-probe: checking bus 1, device 4: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3.2"

Jul 26 01:38:47 patchbox mtp-probe: bus: 1, device: 4 was not an MTP device

Jul 26 01:38:47 patchbox systemd-udevd[1293]: Process ‘/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev’ failed with exit code 1.

Jul 26 01:38:47 patchbox systemd-udevd[1290]: Process ‘/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev’ failed with exit code 1.

Jul 26 01:43:36 patchbox pd[619]: watchdog: signaling pd…

Not sure it means anything.

Looking for mec config file… trying to remember cmds from my Irix days, (nice purple O2, good O2)

syslog.txt (124.2 KB)

found this in mec.service

[Unit]

Description=Run MEC at boot

DefaultDependencies=no

Wants=network-online.target

After=network-online.target

Conflicts=shutdown.target

Before=shutdown.target

[Service]

Type=simple

User=patch

Group=patch

Environment=HOME=/home/patch

KillMode=process

Restart=always

WorkingDirectory=/usr/local/MEC

ExecStart=/usr/local/MEC/mec-app osckontrol.json

#ExecStart=/usr/local/MEC/mec-app pushkontrol.json

Need a line here to unable the Pico?

just guessing at this point…

cheers -Tefman

sorry that’s enable the pico…

Also found three pico files:
picokrtl, picoosc and picopd, all .json files that look similar in code.

oh and a pico.ihx file. any of this useful? Do I reference any of these in the mec.service file?

Best -tefman.

This line says which config file to use , osckontrol in this case - you’ll need the picoktrl for one iirc

If you look inside the json file, you’ll see part of it is configuring the Pico, and another part is setting up the connection to orac.
I can’t remember offhand if picoktrl is complete, I’d need to check it.

I have the pico working on the Organelle (classic, not M) using the picopd.json. (Exciting!!!) The organelle sort of recognizes the tau, but makes weird crunchy asynchronous chord noises a few seconds after touching the keys. (Overwhelmed with too much info?).

I tried setting up a PiSound (Raspberry pi 3) with Orac, got things working okay with MEC and the remote app. I tried switching the mec.service line to point to picopd.json, and restarting MEC did not seem to recognize the pico. I then tried picoktl.json, and then picoosc.json, with no luck there, either. I’ll try to get some logs and see what is going on.

Silly question: Can the current MEC handle talking to both the remote app, AND talking to an eigenharp with a cleverly enough designed .json file, or am I being greedy?

I think Mark is saying that the picoktrl.json is referenced in the above file…

Mark do you wanna see what’s in my non working picoktrl.json?

Best -tefman

Guess I’m confused. looked at osckontrol… no mention of any pico files.
Think I mis-understood your post. Should the picokcrtl, picoosc and/ or picopd.json files get referenced in the mec.service file? Would try it
but I don’t wanna break my pico.
cd local

Thanks -tefman

Bit the bullet and referenced picoktrl.json in mec.service.
No pico. With no remote up, da3v… btw thanks for the post.

best -tefman

It looks like the service is running from /etc/systemd/system/mec.service, not the one in /usr/local/MEC

I just tried each of the three pico confs in /etc/systemd/system/mec.service. It does look like the changes are getting picked up now, but my pico is still not making sounds. Progress, I think.

It looks like blokas is running an instance of MEC with its own .json file as well?
root 504 0.0 0.0 1940 416 ? S 03:34 0:00 /bin/sh /usr/bin/mec /etc/mec-blokas.json
root 510 0.7 0.2 43592 2632 ? Sl 03:34 0:06 mec-app /etc/mec-blokas.json

Maybe this will make more sense to me after I get some sleep.

Thanks for finding the running mec.service, da3v. Me too… need sleep. -tefman

So I referenced picoktrl.json in the /system/mec.service, and nothing
happened. Nothing in my syslog either… that I could tell. Da3v what logs are you looking at? Thanx

Could it just not currently work on a RPI 4?

@tefman, It is not just pi4, since I am using a pi3.

I’ve been primarily looking at output from journalctl -u mec

Tonight I cycled through the json files, and learned a couple of things:

  1. There were failures due to pico.ihx not being where the service was expecting to find it, so I created the folder structure and put a copy of pico.ihx there.
    Jul 30 02:47:42 patchbox mec-app[1476]: log:unable to open IHX firmware: ../eigenharp/firmware/./resources/pico.ihx

  2. picoktrl.json had a spare comma following the penultimate curly brace. I removed it, and started seeing the same error I was seeing with the other two json files:

“realtime: Operation not permitted”

Jul 30 04:15:34 patchbox mec-app[1893]: log:using firmware …/eigenharp/firmware/./resources/pico.ihx
Jul 30 04:15:34 patchbox mec-app[1893]: realtime: Operation not permitted
Jul 30 04:15:34 patchbox mec-app[1893]: log:usbdevice_t::impl_t::start_pipes() : pipes started!
Jul 30 04:15:34 patchbox systemd[1]: mec.service: Main process exited, code=killed, status=11/SEGV
Jul 30 04:15:34 patchbox systemd[1]: mec.service: Failed with result ‘signal’.

I’ve pasted the journal logs for all three .json files at https://pastebin.com/rdBH3Yhb

Tomorrow I’ll look at dev rules per this thread: https://forum.critterandguitari.com/t/eigenharp-mec-query/4164/21?

Bless you sirrah for your Linux prowess.
I’ve been digging around a bit but you know how to find stuff.

So anything I can do to get this working?

U seem close.

Thanx and my very Best -Tefman.

I think I broke the pd remote control either by removing your comma or
just adding the picoktrl.json to mec.service. Removed both the local and
system picokrtl.json ref. in mec.service, now the main pd patch connects to ORAC now. Will see which one breaks it.