Forums > MaxMSP

APC40 interception

August 1, 2009 | 3:55 am

Does anyone know how to make a Max Patch that will intercept MIDI between Ableton and the APC40, but still allows the handshake through so that the default behaviour of the APC40 is available if nothing is actually changed?

I’ve been trying to do this all morning: and while I can get standard MIDI to/from the APC40 through Max, I can’t get all the automatic functionality to work.

Any ideas?


August 1, 2009 | 6:42 pm

I dont think you are going to be able to intercept the midi from the APC to Live. Here are the issues and resolutions I have run into when building my control interface patch in Max:

The APC itself functions pretty similarly when it is synced to control live and and not (im talking about actually having it setup as a control surface in Live’s preferences). Unfortunately when it is in Control Surface setup, I havent found a way to change any of the assignments of knobs, faders, etc.
My solution to this problem is to build the entire control patch in Max, and CC assign the parameters I want to keep with ctlout (which are track faders, solo..) I dont want to use clip triggering so I havent ported the grid buttons to clips, although im sure it would be fairly simple.

Its easy to setup because all the buttons are Midi notes, and the knobs and faders are CC. If you do a search there was a thread not long ago with much more info on the note mappings and such.


August 1, 2009 | 7:48 pm

Hmm. It’s definitely possible: I’ve got it working in Bome’s with no problen, but I prefer Max.

Essentially, you route the APC’s MIDI to Bome, then inside Bome you route APC MIDI-in to Bome MIDI-out, and vice-versa.

Then you select Bome’s MIDI translator In/Out as an APC40 control surface inside Ableton: and it successfully performs the handshake through Bomes and has full functionality.

The idea then is to intercept specific MIDI notes and use them to toggle MIDI translation presets within Max: like the NativeControl folks do.

Could you not change the assignment of the controls inside Max, by writing two-way mappings? E.g mapping 1/17 to 9/17?

I’ve looked through the MIDI schema for the APC, and it looks like channels >= 9 are free for the taking.


August 3, 2009 | 1:02 pm

This patch should do the trick.

All the ‘control’ communication happens via midi notes and cc, so can be extracted from a midiin object via midiparse for you to store/re-route as you see fit.

The handshake communication is sent via sysex so can be sent directly through the patch unchanged.

Obviously you’ll need to load the patch/set the midi IO ports appropriately before selecting the apc40 as a control surface in live.

– Pasted Max Patch, click to expand. –

August 3, 2009 | 8:58 pm

how can you re-route messages going to Live from this? Whenever the APC is setup as a control surface, the messages seem to go directly from the APC to Live without any way to control which ones get through. Your patch seems to just display what is coming from the APC which is done purely from a Midiin object.

Printing the sysex information sent to the APC from Live when connecting it as a control surface seems useless since there are no lists, only a lot of numbers sent individually.


August 3, 2009 | 9:10 pm

Is there anything non-obvious about what I have to do to get the MIDI I/O ports configured correctly?


August 3, 2009 | 11:58 pm

The crux of this is that rather than Live communicating to/from the APC directly you are doing it THROUGH a max patch. As an Os X user I would do the following:

In Live select "APC40" as a control surface with ‘input’ as "from MaxMSP 1" and ‘output’ as "to MaxMSP 1"

Then in the Max patch on the ‘Live to APC 40′ side:
– select "to MaxMSP 1" as the input
– select "APC40" as the midi output

In the Max patch on the ‘APC40 to Live’ side:
– select "APC40" as the input
– select "from MaxMSP 1" as the output

The patch will now pass all sysex data used by Live/APC40 for the handshake. Any ‘control’ data (midinotes/cc etc) can be intercepted via the midiparse objects for you to use as you wish. You need to connect up the midiin/midiout objects on each side to restore ‘normal’ operation….

If you are a windows user you will have to use something like MidiOx to perform the inter-application midi routing.

Hope that helps.


August 4, 2009 | 12:06 am

I got it now, thanks for clarifying that. Now lets see if I can de-code some of the sysex messages to build my own APC templates.


August 4, 2009 | 12:11 am

Awesome! There are a few things in this patch I don’t follow, but it looks fairly simple.

Question: does the APC use Sysex for anything but the handshake?


August 4, 2009 | 7:50 am

I guess max for live will solve any questions like that
and I guess you’ll wait for it too.

with my protodeck, I’ll use python live door in order to control and get feedback from live.

code is here : http://code.assembla.com/protodeck/subversion/nodes/src/python/ProtodeckController/protodeck.py

it isn’t finished/adapted to my hardware cause I’m just finishing wiring in my box
blog is here: http://www.julienbayle.net/diy/protodeck/blog/

I juste hope max for live will be released SOON !!!


August 4, 2009 | 11:30 am

Good news!

I got this working: one thing to watch out for. If you’ve got a default MIDI routing that just routes MIDI in to MIDI out, this will include sysex. Ableton is precious about its magical handshake and refuses to recognise the APC40 if the sysex gets passed twice.

Make sure *not* to pass through any sysex MIDI outside the locked-down sysex in/out path or it won’t work.


August 5, 2009 | 7:16 am

ok Will.
where did you get these informations?
are there some API/specifications infos available ?


August 5, 2009 | 8:41 am

Yes. People have mapped out the APC in great detail. Look at nativecontrol.com

On the Ableton forums if you search you can find info on the MIDI mappings for the APC40.


August 5, 2009 | 10:02 am

nativecontrol.com doesn’t work here (?!)

but the most great things is the Live side.
I mean, the Live API that everyone could use with all controller that work with midi and/or OSC.
Live API will be official with max for live.
Python inspection has been done for 7.0.16 and it drives us to use python interface instead of max patches.
BUT max for live will bring us to easier days


August 8, 2009 | 8:20 pm

Hi folks,

I’ve been using a similar workaround involving virtual Midi ports to change the default clip launch pad colors using Midi Pipe. Have you all tried this with the new 8.0.5 betas to see if this breaks your functionality?

I ask because there has been a change that seems to bar us from using virtual Midi ports with an APC40. Check out the following post on Ableton’s forums and please chime in if this is a problem for you.

http://forum.ableton.com/viewtopic.php?f=1&t=121477&p=956412#p956412


August 11, 2009 | 3:58 pm

So then, the Live/APC40 handshake.

Anyone getting anywhere with that? Here is my contribution to figuring it out and opening up the ‘red box’ for use from a Max Patch….

The handshake consists of 5 sysex strings exchanged between Live and the APC when it is selected as a control surface.

String 1 (From Live) – ‘APC40 discovery’ message:
240 126 0 6 1 247 240

String 2 (From APC40) – ‘APC40 present’ message:
240 126 0 6 2 71 115 0 25 0 1 0 0 0 127 127 127 127 0 75 2 0 9 0 3 0 2 3 8 0 0 5 6 3 247

After the inital bytes of this message (including the Akai sysex manufacturers code) are a load of digits (all those after ’115′) that ‘could’ be serial number/firmware number etc…. I do not know

If an ‘APC present’ message is not sent to Live no further communication occurs. You can ‘manufacture’ an APC40 present message that will cause Live to send it’s subsequent two sysex strings; the shortest legal ‘APC40 present’ I can produce is:
240 126 0 6 2 71 115 0 0 0 0 0 0 0 247

String 3 (From Live) – ‘Live acknowledgment’ message:
240 71 0 115 96 0 4 65 xx xx xx 247

Live responds to confirm it has recognised the presence of an APC40, including the Live version number (xx xx xx) in the message (e.g. 7 0 16)

String 4 (From Live) – ‘Handshake Query’ message:
240 71 0 115 80 0 16 0 0 mm nn nn nn nn nn 0 0 nn nn nn nn nn nn 247

Where mm is always either 0 or 1, and the "nn" bytes are always between 0 and 15. The rest of the message is ALWAYS the same; only the mm/nn bytes differ. It is from these values that the APC40 must generate a correct response…

From the midi specification we know that ‘data bytes’ in a sysex message must have a zero as their msb. This leaves 7 bits available for data. If only the four lsb’s are used for data values between 0-15 are obtained.

I hypothesise that in this case the four lsb’s from two subsequent "nn" bytes are being combined to produce a full (8-bit) byte (with value between 0 and 255).

This means the ‘handshake query’ message transfers SIX bytes (between 0 and 255) to the APC.

String 5 (from APC40) – ‘Handshake Response’ message:
240 71 0 115 81 0 16 rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr 247

Every ‘handshake response’ from the APC40 is identical except the 16 "rr" bytes returned (which differ each time). Again rr is always between 0-15. This supports the hypothesis that TWO ‘sysex data bytes’ are being used to transfer a single numerical byte (by combining the four lsb’s of two "rr" bytes).

The APC40 therefore uses some algorithm to convert the SIX bytes (between 0-255) sent by LIVE into EIGHT bytes (between 0-255) which it returns. If these match the bytes Live expects the lovely red box appears….

That concludes my observations.

Anybody want to chime in with potential algorithms for turning six bytes into eight???


August 11, 2009 | 10:17 pm
Quote:
Anybody want to chime in with potential algorithms for turning six bytes into eight???

I guess you could use padding.

YOu can check it too:
my protodeck says "hello" to Ableton Live via a python script interface like that:
http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_2/main.c
check the function NotifyReceivedByte

you can check the python script too:
http://code.assembla.com/protodeck/subversion/nodes/protodeck/python/ProtodeckController/protodeck.py

basically, the framework is:
protodeck < ==> python script interface < ==> Ableton Live

hope it will help!

(asap Max for live will be released I’ll translate the python in a big patch, more maintenable)


August 14, 2009 | 12:55 pm

I have made a patch that ‘emulates’ Live and communicates directly with an APC40. The patch will produce a "handshake" in the format Live uses EXCEPT with the critical ‘handshake bytes’ user defineable.

The idea is you can ‘invent’ a handshake, perform it with an APC40 and see what ‘handshake bytes’ it returns.

By sensibly using different ‘invented handshakes’ the handshake algorithm could theoretically be figured out.

Alas I do not have an APC40, so hand over this to another willing participant.

Here is the patch. Though it is untested (not owning an APC40) I am confident it should work. I would be interested in hearing back from anyone who tries this out….

The goal of course is to figure out the handshake so that a Max patch can be made that ‘emulates an APC40′, opening up the red grid/clip launching etc.

Obviously this then opens up this functionality to monomes/custom midi hardware…..

– Pasted Max Patch, click to expand. –

August 17, 2009 | 8:39 pm

OK it looks like you guys got it all sorted out. This is Shane from Akai. Everything is standard midi except the challenge which is sysex. You don’t need to do anything else with sysex. You must individually pick and intercept what you want to do what with between the apc and then pass that on to live. It took me 16 hours to make my workaround remapping. Note, if you want whatever your remapped button is to light when you change it in Live you’ll need to reinterpret and translate on the way back in. Also, you’ll likely need to turn notes into cc’s and vice verse as some ableton controls like notes for on off states better than cc’s.

You can see my demo of max remappings on you tube "APC40 Extended"

My advice too is just to wait for Max For Live though.


August 17, 2009 | 8:41 pm

if only we could have infos about max for live release date . . .


August 17, 2009 | 9:30 pm

Yes Ableton does not tell us these things :0
I don’t think anyone really knows… when it’s pretty stable might be hard to predict


August 17, 2009 | 10:05 pm

Ah one more thing I remembered, rather than have everything come through from the APC40 and then have to filter, when you build your remappings, ONLY let through what you will use. It’s more work in some ways to do it inclusive rather than exclusive, depending on how much default mapping you want, but it will keep things manageable and scalable when first starting.


Viewing 22 posts - 1 through 22 (of 22 total)