Pico on Orac: Just Plug it in?

Eigenharp
#8

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

#9

sorry that’s enable the pico…

#10

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.

#11

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.

#12

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?

#13

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

#14

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

#15

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

best -tefman

#16

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.

#17

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

#18

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?

#19

@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?

#20

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.

#21

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.

#22

FYI I did not move the pico.ihx hex file.

best tefman.

#23

OK, so just adding the ref to picoktrl.json to mec.service in system breaks the pd remote control patch:

from pd window:

warning: 13 removed from poll list but not found
LISTEN:: listen 6101
connecting to port 6100
SEND:: connect 192.168.1.130 6100
recv: Connection refused (61)

works again if I remove it.

did not move the .ihx file.

-tefman

#24

Got it!

  1. As far as I can tell, the remote control patch only works with osckontrol.json. At some point, I’d like to figure out how to get MEC to handle traffic from both the pico (or preferably the tau) AND the remote control patch at the same time, but for now I’m fine with switching between the two. (Mark is a busy, generous guy, and I hate to pester him about stuff that I should be able to work out on my own.)

  2. picopd.json will work just fine if run by hand, so there is some permissions weirdness when MEC is run as a service.

  3. There is no 69-eigenharp.rules in /etc/udev/rules.d. Sudo copying to there, running sudo udevadm control --reload-rules, and then rebooting seems to have fixed the issue. My pico now works.

Things I did:

  1. Create an Orac patch that has brds in slot 1, and midi in channel set to 0. Saved it as new, and then hit the save button to make sure it loads when orac loads. (Might not be able to hear pico with default patch, even if everything else is fixed?)
  2. edit /etc/systemd/system/mec.service and make the entry point to picopd.json
    2a)refresh the systemctl daemon
  3. create folder structure for the ihx file, and copy it there
  4. sudo cp 69-eigenharp.rules /etc/udev/rules.d
  5. refresh the rules
  6. reboot

Before you get too carried away, I’d try running mec by hand, just to make sure that pi4 isn’t causing additional complications.

cd /usr/local/MEC
sudo ./mec-app picopd.json
(control-c to exit)

snippets for the rest of the steps from my history. Make sure you understand what you are doing, as some of these can mess up your pi if you or I mistyped.

sudo systemctl stop mec
sudo pico /etc/systemd/system/mec.service
sudo systemctl daemon-reload
sudo mkdir -p /usr/local/eigenharp/firmware/resources
sudo cp /usr/local/MEC/pico.ihx /usr/local/eigenharp/firmware/resources
sudo cp /usr/local/MEC/69-eigenharp.rules /etc/udev/rules.d
sudo udevadm control --reload-rules
sudo reboot now

(yes, using the pico text editor on that second step might seem “kind of meta”)

Note: to get a Tau working, you also need to

sudo cp /usr/local/MEC/psu_mm_fw_0102.ihx /usr/local/eigenharp/firmware/resources/

#25

so the osckontrol section that is interesting is (in mec section)

        "oscdisplay"  :  {
            "listen port" : 6100
        },

        "kontrol"  :  {
            "listen port" : 6000
        }

to this to get the pico/working we need this section, again in mec section

        "eigenharp" : {
            "voices" : 4,
            "pico" : {
                "mapping": {
                    "calculated": {
                        "keys in col": 9,
                        "row multiplier": 1,
                        "col multipler": 5,
                        "note offset": 48
                    }
                },
                "leds" : {
                    "green" : [1],
                    "_orange" : [ 1 ],
                    "_red" : [ 1 ]
                }
            },
            "tau" : {
                "mapping" : {
                    "calculated-wrong": {
                        "keys in col": 16,
                        "row multiplier": 1,
                        "col multipler": 4,
                        "note offset": 20
                    }
                }
            },
            "alpha" : {
                "mapping" : {
                    "calculated": {
                        "keys in col": 24,
                        "row multiplier": 3,
                        "col multipler": -1,
                        "note offset": 26
                    }
                },
                "leds" : {
                    "green" : [ 48, 52, 56,60, 64, 68 , 26, 74, 34, 82, 42, 90],
                    "_orange" : [ 1 ],
                    "red" : [ 30, 78, 38, 86, 46, 94 ]
                }
            }
        }

the other side we also need, is how to talk to orac,
this can either be done via mpe or osc

e.g.

    "mec-app"  :  {
        "outputs" : {
            "midi" : {
                "virtual" : 0,
                "voices" : 4,
                "pitchbend range" : 48.0,
                "device" : "Pure Data:0"
            },
            "_console" : {
                "throttle" : 0
            }
        }
    }

note: the device can differ slightly depending on platform name - use aconnect to check

#26

Mark, sorry

just a bit confused. Should these pieces of code be one file, referenced with in mec.service?

the three pico.* files in MEC have bits of this code separate.

Da3v & Mark thanks for all the info, I will read twice, think about it… then act.

-tefman

#27

Yes, and mentioned earlier these are configuring mec in different ways for different purposes.
Mec can be configured in many different ways for different tasks - it was not created initially for Orac