Akai APC40 hax


#1

I have a used, trashy Akai APC40 controller. I found an article from 2009 with a bunch of busted links. My software stack is Puredata, Linux, JACK. I’m pretty good at software dev but I’m unfamiliar with the Monome software environment.

Is it a good idea to begin to port some of the monome grid studies for pd to work as expected with Akai’s mass produced advertisement for Ableton? The article implies it could be possible to intercept the Ableton specific SysEx!

Despite going backwards in history, would a MIDI => OSC piece of hardware be even relevant?


#2

You’d have to create a SysEx to OSC translation layer. There’s some precedent in Gridlock which does this for Launchpads.
http://www.sigabort.co/gridlock.html

That being said, reviews have been really mixed with regard to folks getting Gridlock to work with various monome apps.

On the one hand, it’d be cool to breathe new life into these mass produced products. On the other hand, it sounds like a nightmare of kludges and workarounds.


#3

I don’t think it would be much of a kludge. I would need the full table of OSC namespace for Monome (I can probably find this in the github repo) and the full list of MIDI messages from the APC40. From there the software might have to do some number scaling tricks but I think it would be a straight forward “listen to a podcast and do data entry” kind of job.


#4

here’s the OSC protocol for monome devices:
https://monome.org/docs/osc/


#5

booya, I’ll give this a shot today.

It looks like the shortest path is to build something similar to the serialosc server but with midi on one end. This would keep all the PD tutorials intact because all the protocol mapping would happen inside the server.

UPDATE: I just figured out how to send arbitrary sysex bytes to put it into “ableton mode” (without using Ableton) which turns it into an 8x8 grid. This is going nicely. I can control the LED’s by sending the unit noteon/noteoff messages via PD [makenote]. I think now comes the plumbing part…


#6

ooh, nice approach! …


#7

I got a proof of concept on github

Video of the default state of the unit, sending sysex to enable “ableton mode” and Puredata sending values to light up the LEDs


#8

Sweet! Oh hai noisebridge! :slight_smile:


#9

One day later and I got the data mapping between the basic MIDI and grid tuples worked out and libraries that can handle the I/O.

Here’s the toolkit I’m working with

  • python 2.7
  • python-midi
  • python-osc
  • ALSA sequencer for hardware MIDI communication

The concurrent realtime I/O is more difficult than I imagined. I would like to have a drop in replacement for serialoscd. I pushed my commits thus far and I’ll continue working on it. If anyone else has this hardware and is interested, lemme know.

It’s Linux only because that’s what I know. I imagine a macOS hardware interface would be useful as well.


#10

I’m curious about what project(s) you’re planning with your grid on linux once you got the serialoscd emulation layer cooking!


#11

Nothing specific yet. I’m using this as a chance to do software development work with controller protocols I’ve been curious about for a long time in an environment that isn’t PD.


#12

It’s a really difficult thing to approach! I was making good progress using common lisp & the same ‘concurrency channel’ abstraction that’s part of go (go the programming language). It’s basically like a ‘unix pipe’ that can be read/written to from different threads, either blocking or non-blocking. Maybe there’s a library you could hook into for this kind of inter-thread communication? nanomsg could be helpful if you can find some bindings ready to rock?

I’ve already got 2 unfinished midi performance sequencer projects (an initial ugly one & an aborted rewrite) written in common lisp… They both used this kind of concurrency. But I was getting more stuck on sequencer design - my plumbing on the second attempt worked well…

So I do think that, overall, an approach to concurrent i/o using nanomsg or similar is to be recommended!


#13

Turns out the python-midi library was designed primarily for reading and writing midi files, not realtime communication with hardware. I found the rtmidi python bindings, which provides a user defined callback function on MIDI input. Gonna test that out today.

There’s also a python-osc library that looks like there is an OSC address => callback function matching feature.

I wonder if I’ll need a third thing to glue together these two event loops and callbacks?


#14

Have you looked at pymonome? Not sure if you’ll be able to use it directly, but it can at the very least give you some ideas :slight_smile: it uses asyncio


#15

totally different tack, but you may like to know that the monome serial protocol is pretty straightforward. so yeah i’d go for the hardware route, why not

a programmable adapter that took hardware midi and emitted monome serial would be easy to make and widely useful. (i probably have some arduino emulator code bits lying around that could be posted). i don’t know if its ever been tested but i think you can just tell serialosc your serial device has M buttons and N encoders and &c.

(actually guess i don’t know if apc40 even has hardware midi out… so maybe nevermind)


but for software, yeah emulating all of serialoscd sounds like a lot. i’m thinking of all the multiple device and configuration managment stuff it does.) for a single device it seems not too bad: one thread to read midi / send osc, one other thread to read osc / send midi. i don’t even see why they’d need much synchronization

in C i guess i’d use liblo; gives you an OSC server thread with a callback and lets you dispatch OSC client messages asynchronously from any thread. (i guess pyosc is similar.) and i guess portmidi if you don’t want to deal with sysfs or alsa directly. (dunno about realtime midi in python. sounds fishy)


[ed: omg, lol]

Will the secret handshake prevent us from turning a Monome + BCR into an APC?
Yes.


#16

I used to emulate monome in various ways when serialosc was strictly zeroconf-based. Without too much effort you could make any program pretend to be a grid or an arc (even mobile devices/apps connected to the same LAN).

Now it seems you have to emulate serialosc for the discovery mechanism to work, so pymonome would not be of much help here, unfortunately.


#17

I did it!

Implemented the /grid/led/set, /grid/led/all and /grid/key namespaces.

I know some of the secret sysex handshakes…


#18

@zebra what is BCR? The APC MIDI implementation is documented in my repo with a PDF from Akai. I got the Sysex to enable “Ableton mode” without Ableton.


#19

A Behringer rotary controller (I presume!)
https://www.music-group.com/Categories/Behringer/Computer-Audio/Desktop-Controllers/BCR2000/p/P0245


#20

huh, there is one encoder on the APC40 and it outputs a CC with deltas as 127 when turned counter clockwise and 1 as clockwise when rotated with slow constant movement. If I spin it as fast as I can with my finger it’ll output up to 33 so I guess that’s the step over clock tick.