Patchbox and ORAC

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

BTrailor · October 12, 2020, 1:32pm

Here is what that command returned.

I should mention that it appears that mono synths strictly stick on the root notes, while poly synths all appear to be sticking with all notes.

Giedrius · October 12, 2020, 1:38pm

At first glance, it looks ok. But just in case, try running these commands, while mec & orac is already running:

aconnect -x
sudo systemctl restart amidiauto

And check for stuck notes, make sure to try to play the stuck notes themselves.

BTrailor · October 12, 2020, 1:48pm

Ok. Gave that a whirl and things are still wonky. I did discover more about the peculiarity though. It would appear that (at least while using a poly synth such as analog style) The stuck note behavior only applies to single notes so if I hit and release 2 or more notes at the same time it behaves normally note on/note off, but when hitting a single note it sticks on every time.

BTrailor · December 3, 2020, 10:18pm

Hey again, @Giedrius. I’m coming back to this again with hope of solving this time. I had a brief exchange with @thetechnobear about this issue. What he had to say was illuminating.

what looks to be happening is…

MEC is listening to MIDI events from the Push 2, so that it can interpret them, and send the right midi messages to pure data/orac.

but amidiauto is also connecting the Push2 directly to pure data…

this means Pure Data is getting both duplicated data, and also some data it’s not expecting.

It was pointed out that there was work done in the past around this developing some amidiauto rules applied through the .conf. I noticed that ORAC is packaged with that .conf file, but it doesn’t live in /etc/amidiauto.conf as expected. Is it possible that this issue is simply that amidiauto is not receiving the appropriate rules to cooperate well with MEC and ORAC?

Giedrius · December 4, 2020, 9:15am

Once the ORAC module is activated through patchbox, it changes the location of the rules file that amidiauto makes use of, check /etc/environment file, it should contain this line:

AMIDIAUTO_CFG=/usr/local/patchbox-modules/orac/amidiauto.conf

Also sudo systemctl status amidiauto:

patch@patchbox:~ $ sudo systemctl status amidiauto
● amidiauto.service - ALSA MIDI autoconnect daemon
   Loaded: loaded (/lib/systemd/system/amidiauto.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-12-04 09:11:24 GMT; 1min 50s ago
 Main PID: 24530 (amidiauto)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/amidiauto.service
           └─24530 /usr/bin/amidiauto

Dec 04 09:11:24 patchbox systemd[1]: Started ALSA MIDI autoconnect daemon.
Dec 04 09:11:24 patchbox amidiauto[24530]: Reading rules in '/usr/local/patchbox-modules/orac/amidiauto.conf'...
Dec 04 09:11:24 patchbox amidiauto[24530]: Allowing '*' -> '*'
Dec 04 09:11:24 patchbox amidiauto[24530]: Allowing 'MEC MIDI' -> 'Pure Data'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing 'MEC MIDI' -> '*'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing '*' -> 'MEC MIDI'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing 'Push 2' -> '*'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing '*' -> 'Push 2'

To make sure Push2 is not connected to PD directly, you can run aconnect -lio and see the actual MIDI connections.