Patchbox and ORAC

thetechnobear · March 27, 2019, 6:03pm

hi @Giedrius
Im working on getting orac working on patchbox OS… (console only)

a few things are confusing me slightly…

A) how can I stop the mec-app you have running , as I need my own, with its own config
it doesn’t appear to be started with a systemd service?

(Ive a much newer build, so I cannot just use what you have there with a different config )

B) Im running PD from a serviced service

Mar 27 17:49:49 patchbox systemd[1]: Started Run Orac at boot.
Mar 27 17:49:51 patchbox pulseaudio[602]: [pulseaudio] module-jackdbus-detect.c: Unable to contact D-Bus session bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 27 17:49:51 patchbox pulseaudio[602]: [pulseaudio] module.c: Failed to load module “module-jackdbus-detect” (argument: “channels=2”): initialization failed.
Mar 27 17:49:51 patchbox pulseaudio[602]: [pulseaudio] main.c: Module load failed.
Mar 27 17:49:51 patchbox pulseaudio[602]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 27 17:49:51 patchbox pulseaudio[602]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 27 17:49:51 patchbox pd[573]: opened alsa client 132 in:1 out:1
Mar 27 17:49:51 patchbox pd[573]: Cannot connect to server socket err = No such file or directory
Mar 27 17:49:51 patchbox pd[573]: Cannot connect to server request channel
Mar 27 17:49:51 patchbox pd[573]: jack server is not running or cannot be started
Mar 27 17:49:51 patchbox pd[573]: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Mar 27 17:49:51 patchbox pd[573]: error: JACK: Failure. Is JACK running?

my config is

[Unit]
Description=Run Orac at boot
DefaultDependencies=no
Wants=network-online.target
After=network-online.target
Conflicts=shutdown.target
Before=shutdown.target

[Service]
Type=simple
#User=pi
#Group=pi
#Environment=HOME=/home/pi
User=patch
Group=patch
Environment=HOME=/home/patch
KillMode=process
Restart=always
LimitRTPRIO=infinity
LimitMEMLOCK=infinity
WorkingDirectory=/usr/local/orac
ExecStart=/usr/bin/pd -rt -alsamidi -nogui -audiobuf 4 mother.pd main.pd

[Install]
WantedBy=default.target

if I run pd as the patch user and run the ‘test audio midi’ in pd, it works ok - though I do see Audio I/O error, but still sound comes thru

this also works, when run as patch users

cd /usr/local/orac
/usr/bin/pd -rt -alsamidi -nogui -audiobuf 4 mother.pd main.pd

so it appears its to do with the service?!
which seems odd, as its running as the patch user!?

thetechnobear · March 27, 2019, 6:17pm

I think ive fixed it… like your button service needs to important the environment file,
so added

EnvironmentFile=/etc/environment

and seems ok, just rebooting now to check

thetechnobear · March 27, 2019, 6:41pm

EDIT: ok, that fixed it…

so now I need to figure out …

a) how to kill your mec-app
can’t find out whats starting it at the moment!

b) mec … I need to know what port PD (orac) is going to be running on
but every time I start it seems to switch between 132 and 133.

I guess this is the TouchOSC bridge, so I could disable that?!

c) I think you mentioned somewhere here that you have a process that is auto connecting devices to PD , correct?
is there a way to stop that for some devices?

this is kind of confusing me:

client 133: 'Pure Data' [type=user,pid=588]
    0 'Pure Data Midi-In 1'
	Connected From: 20:0, 130:0, 132:0, 129:0, 134:0[real:0]
    1 'Pure Data Midi-Out 1'
	Connecting To: 20:0, 130:0, 131:0, 129:0[real:0]
client 134: 'MEC MIDI OUTPUT' [type=user,pid=876]
    0 'MIDI OUT        
	Connecting To: 133:0[real:0], 20:0, 130:0, 131:0, 129:0[real:0]

so MEC is connecting to PD directly, I guess amidiauto is doing the rest?

(the ‘issue’ is, when I connect my Push 2 , its no good the midi data going to PD, I need to to go to MEC only, so it can process the midi, and proper midi data )

I could stop amidiauto, but then user will have to manually attach other controllers to PD

thoughts?

ok, not ideal but seems to be starting ok now

what Im doing is:
systemctl disable amidiauto - to stop it attaching things I dont want
systemctl disable touchosc2midi - to stop the extra virtual midi ports
systemctl disable pisound-ctl - stop the blokas version of mec-app

just one last step, to make MEC start on button press… (I think)

the general intention is (of this install)
orac will start automatically, you can then play with a midi keyboard (or whatever) , and change presets via program changes…

then if you want to edit/modify/midi learn etc, you can press the pisound button, to start MEC,
then connect with your phone/computer , or push 2 to remote control.

all done except that button press

Giedrius · March 28, 2019, 7:53am

Yeah, turns out systemd services by default have no environment variables, while all user processes use the environment from /etc/environment. It contains the essential JACK_PROMISCUOUS_SERVER=jack, so a single Jack server is shared between the users on the system.

Regarding amidiauto and MEC, you want to have all hardware MIDI controllers connected to MEC, but MEC’s output only connected to PD? We have to add some rules to amidiauto, I think hardcoding for now would be the simplest solution, but once some desired patterns of its behavior start to emerge, we may come up with some text configuration system. See the source code here.

Can two different versions of MEC run at the same time if they are using different ports to communicate? We could make sure that our version of MEC build does not interfere with yours.

touchosc2midi should be treated as a regular hardware MIDI device. Does its port numbers interfere with your uses? Unfortunately I don’t think this can be changed without breaking TouchOSC functionality, as the TouchOSC app assumes that the particular ports for OSC bridge will be used.

thetechnobear · March 29, 2019, 11:06pm

no, not quite

I don’t want amidiauto to connect:

the virtual mec midi output to PD
the push 2 to anything

this is because mec is explicitly already making these connections.
all other midi controllers could be connected to PD thats fine

as you say, probably some kind of rule/filter to exclude certain also midi devices
(best to be filters on both input and output side I think )

sure, its all configurable…

of course, I suspect we could just update the version you have installed, it should be backwards compatible, but as i don’t have an android phone, I cannot test this.

the advantage of one instance, is that then iPhone users could use my lemur apps to control the patches you built. (again untested)

nah, the only issues is, both PD (orac) and touchosc2midi create virtual ports, so depending on which ‘starts first’ , PD might end up with port 132, or 133 … and Ive got this number coded in my mec configuration.
I could do some ‘naming matching’ in MEC to find the actual port, just im a bit focused on getting Orac 2 out the door… so probably not happening right now

anyway, for the beta, its probably all ok as it is for now…

Giedrius · March 30, 2019, 10:45am

I think you can use client names like “PureData:0” for ALSA MIDI ports with ALSA utilities and APIs, maybe string names already happen to work with MEC? If so, confusion between touchosc2midi and PD would be solved in a future proof way. (at first I thought you were talking about UDP port numbers )

This is how our version of MEC deb package is built: GitHub - BlokasLabs/mec-pkg - it has MEC as an external and the build scripts to build it. We did disable some stuff which weren’t used in the Pisound App, we could re-enable necessary things.

Did the OSC API remain unchanged since our build?

Anyway, I think I can play around with the latest version of MEC and our app some time next week.

Giedrius · April 1, 2019, 1:53pm

Regarding touchosc2midi - looks like RtMidi does not provide the proper APIs to allow taking advantage of ALSA port name matching rules, but I just tried a quick idea on how to make it work, and here it is:

The whole idea is using snd_seq_parse_address to get the client:port address from a string and then figuring out which RtMidi port id this maps to.

This allows using for example “Pure Data:0” instead of a string like “Pure Data:Pure Data Midi-In 1 128:0” to get the right port.

The snd_seq_port_info_t store the PID of the owning process, if the right Pure Data instance would be known ahead of time, the code could be easily extended to make sure it uses the MIDI ports from the right process,

Giedrius · April 1, 2019, 3:01pm

For the time being, I have updated the MEC config the Pisound App uses to use "listen port": 6050, so the two instances don’t conflict with each other when running at the same time. You may do sudo apt-get update && sudo apt-get upgrade to get the update.

Of course we will look into sharing a single instance of MEC, but it might prove difficult to keep everything in a stable working state.

So for compatibility with Patchbox OS, touchosc2midi should be solved, the pisound-ctl will use its own MEC instance for the time being, and I’ll look into adding some simple rules to amidiauto tomorrow. Is there something else to look into?

thetechnobear · April 1, 2019, 3:47pm

cool, thanks for the PR for mec…
its not only better for this, but actually I think it’ll mean the configuration file is more ‘cross platform’,
as this port name seems different on every OS

I think, I’ll use the same mechanism for the underlying MEC devices, like push… to get the same benefit

(ok, I know it breaks multiple instances, but can look at that later)

ok, will do the update…

yeah, sharing version can be problematic… lets see how it goes for now, if we can co-exist thats a good first step… when I get more time, Id like to test one of your patches, to see if its working with my remote interface etc… in practice Im sure it’ll all be fine.

amidiauto - yeah, that would be really handy.

how do you want me to handle a custom button script?

I think those were the only issues…
you may want to take a look at https://github.com/thetechnobear/orac (dev branch, master is really old!)

in particular:
https://github.com/TheTechnobear/Orac/blob/dev/PI/install.sh

this installs mec/orac, so you might have some ideas/thoughts about where things are placed etc.

I’ll obviously remove the ‘disables’ as the above issues are resolved/tested

(you can easily build your own image for testing, simply call ./scripts/create_pi.sh, you’ll see basically a PI is Core+PI, and gets built into pkg/pi )

as you can see its all ‘normal’ stuff
the idea being to make it standard debian, so it’ll basically work on debian install (e.g. Raspbian),
and if they need to hack it (e.g. for arch linux) theres not a lot of changes needed, or custom scripts to go thru.

the things Id like to improve at some point are:
a) use pisound where appropriate … I think it makes most sense to use button to start MEC.
(perhaps this should just call servicectl start MEC… so user can just decide if its the button that starts or its always present on startup!?)
b) debian package
c) some how, remove the user name where its present.
or i guess alternatively, create a user specially for orac?

I think b, c can wait, and (a) I just need to look what I need to do, so it doesn’t ‘disturb’ too much of your image.

my ideal is, anyone can install this quickly/easily without editing, even without linux knowledge, or know what patchbox is, and then it ‘just works’ (hence why I auto start things ) .

but also, if someone is already using the patchbox and knows it, if they install this, they can they can disable/enable bits they want. (e.g. make MEC/Orac start on the button, say in a similar way to they start other pd patches)

anyway, we’re pretty close… im sure it’ll get there

Giedrius · April 2, 2019, 11:00am

I think enabling / disabling the MEC service with the button would be cool, we already have a similar script which you could adapt: pisound/scripts/pisound-btn/toggle_wifi_hotspot.sh at master · BlokasLabs/pisound · GitHub

sudo pisound-config will list any scripts in “/usr/local/pisound/scripts/pisound-btn”, so you can pick which interaction performs what action. Also editing /etc/pisound.conf, you may specify absolute path for an interaction to any place on the system.

We still have an unused “hold the button down between 1-2 seconds” slot, do you think this could work for enabling & disabling the MEC & ORAC service? Otherwise, one of the existing ones should just be remapped.

You can launch the bundled patches with a command like:

/usr/local/pisound-ctl/puredata/puredata_launch.sh /usr/local/puredata-patches/GarageBeat/0_START.pd

You can figure out the entry point of a patch by inspecting the blokas.yml file, and you can get the list of available patches by running /usr/local/pisound-ctl/puredata/puredata_list.sh.

Giedrius · April 2, 2019, 3:32pm

Ok, I’ve made some nice progress with adding rules to amidiauto, please give it a try

To install the new build, do:

git clone https://github.com/BlokasLabs/amidiauto -b amidiauto_rules
cd amidiauto
make
sudo make install

Create /etc/amidiauto.conf with the following contents:

[allow]
* <-> *
MEC MIDI -> Pure Data      # Can also be written as Pure Data <- MEC MIDI

[disallow]
MEC MIDI <-> *
Push 2 <-> *

The strings in amidiauto.conf are the ALSA MIDI client names of the devices. The name matching is done by searching for the provided substring (like ‘MEC MIDI’) in the full ALSA MIDI client name.

amidiauto still works with the very first input and output port provided by the ALSA client.

The middle part can be one of <->, -> and <-. It indicates the direction of connection, from a MIDI output to an input. <-> is a shorthand for specifying the same rule twice, once with <-, and then with ->.

The rules work by evaluating their strength, and giving ‘allow’ priority, in case both ‘allow’ and ‘disallow’ would evaluate to the same strength. The strength of the rules, from weakest, to strongest:

* <-> *                      # Weakest
something <-> *              # Stronger
something <-> something_else # Strongest

So the above config file sets amidiauto to connect every hardware and software MIDI ports together, unless they are either “MEC MIDI” or “Push 2”, and still setting up the connection from “MEC MIDI” to “Pure Data” automatically.

The wildcard rules still are categorizing MIDI ports into ‘software’ and ‘hardware’ ports, and only making automatic connections between the categories. Using the explicit strongest rule is possible to make automatic connections between ports within the same category.

thetechnobear · April 2, 2019, 6:03pm

awesome stuff @Giedrius
looks perfect!

I’ll give it a go tomorrow… combined, they should sort out all the issues I had, so can re-enable things.

hmm, bit loathed to include something with tight timing,
i think really most users struggle with more than just click , and click and hold
even double click causes issues for some, as you need the timing ‘just right’)

and without anyway to give visual feedback (headless) it could lead to frustration.

anyway, I’ll have a look at whats there, perhaps I can make it so the user can choose what works for them?!

miker2049 · April 5, 2019, 6:21pm

just want to say 20 chars very exciting, yall are great

(also very happy to help beta test this )

thetechnobear · April 5, 2019, 6:40pm

theres going to be a beta very soon…
anyone that is interested should subscribe to my youtube channel where it will be announced, with full details … you won’t want to miss it

(oh, and remember the bell icon … otherwise you wont get a notification!)

jazzmess · April 5, 2019, 8:06pm

So hyped !!!

wright-io · July 3, 2020, 8:48pm

Hi: I’m really loving using ORAC with the PiSound and Patchbox! But I’m having some issues trying to use the Push 2 as a controller. I’ve got it to connect and display the ORAC controls, but it seems to somehow disrupt the ORAC modules playback immediately after connecting (the Euclid drums in the demo1 patch stop playing). Then when I push some pads, it starts back up, but the midi communication is somehow strange: Notes are very delayed, and sometimes don’t release. I can Init and load a simple synth and play it, but even then there seems to be high latency and the root note pads seem to hold. I know this all sounds very strange. I wonder if something is configured incorrectly or conflicting.

I would greatly appreciate any help or advice anyone can provide. Thank you!

**patch@patchbox** : **/usr/local/MEC $** sudo systemctl status mec

**●** mec.service - Run MEC at boot

Loaded: loaded (/etc/systemd/system/mec.service; enabled; vendor preset: enabled)

Active: **active (running)** since Fri 2020-07-03 21:38:12 BST; 7min ago

 Main PID: 2441 (mec-app)

Tasks: 8 (limit: 4033)

Memory: 3.2M

CGroup: /system.slice/mec.service

└─2441 /usr/local/MEC/mec-app pushkontrol.json

Jul 03 21:38:12 patchbox mec-app[2441]: Open Push2 :2982:1967

Jul 03 21:38:12 patchbox mec-app[2441]: Push2::init - complete

Jul 03 21:38:12 patchbox mec-app[2441]: KontrolDevice initialise

Jul 03 21:38:12 patchbox mec-app[2441]: KontrolDevice::init

Jul 03 21:38:12 patchbox mec-app[2441]: kontrol device : listening on 6000

Jul 03 21:38:12 patchbox mec-app[2441]: KontrolDevice::init - complete

Jul 03 21:38:20 patchbox mec-app[2441]: KontrolDevice::new client 127.0.0.1 : 6001 KA = 5

Jul 03 21:38:32 patchbox mec-app[2441]: KontrolDevice::Process... remove inactive client 127.0.0.1 : 6001

Jul 03 21:41:10 patchbox mec-app[2441]: KontrolDevice::new client 127.0.0.1 : 6001 KA = 5

Jul 03 21:42:09 patchbox mec-app[2441]: selected preset demo2

BTrailor · October 12, 2020, 1:32am

I’m experiencing this as well @wright-io. Did you ever find a solution?

Giedrius · October 12, 2020, 11:29am

Hey, I think push2 must use some special configuration of ORAC, did you perform that as needed?

BTrailor · October 12, 2020, 12:27pm

Hey @Giedrius, thanks for your swift reply. Can you say more about this? Essentially, I was struggling getting Push 2 running for a minute until I realized the mec.service was loading the osckontrol.json. I modified the service to instead load the pushkontrol.json and that got things up and running, but it is as @wright-io says, the controller is behaving a little strange with note off data sometimes not getting sent and it does appear that this is usually around the root notes, but others stick on as well. Is there a bit more configuring I should have done?

Giedrius · October 12, 2020, 12:30pm

I think that was what I meant.

Once the issue happens, could you post the full output of this command:

aconnect -lio