Wish granted, hackers. The full specification for Ableton’s Push 2 hardware is now online on GitHub, after passionate Live users clamored for its release. And there’s a lot. This isn’t just a MIDI specification (though that’s there). Every minute detail of how colors appear on LEDs gets covered. (The color “white” has its own section. Yeah, like that minute.) Every animation. The pixels that show up on the display. This isn’t just a guide to how to hack Push 2 – though it’s certainly that. It’s a technical bible on how Push 2 works.

Here, the easiest way to express this is actually to post the table of contents:

1. Introduction
1.1. Purpose
1.2. Architecture Overview
2. MIDI Interface
2.1. MIDI Interface Access
2.2. MIDI Messages
2.3. MIDI Mapping
2.4. Sysex Commands
2.4.1. General Command Format
2.4.2. Command List
2.5. MIDI Mode
2.6. LEDs
2.6.1. Setting LED Colors
2.6.2. RGB LED Color Processing
2.6.3. White LED Color Processing
2.6.4. Touch Strip LED Color Processing
2.6.5. Default Color Palettes
2.6.6. White Balance
2.6.7. Global LED Brightness
2.6.8. LED Animation
2.6.9. PWM Frequency
2.7. Buttons
2.8. Pads
2.8.1. Velocity Curve
2.8.2. Pad Parameters
2.8.3. Individual Pad Calibration
2.8.4. Aftertouch
2.9. Encoders
2.10. Touch Strip
2.10.1. Touch Strip Configuration
2.11. Pedals
2.11.1. Pedal Sampling
2.11.2. Pedal Configuration
2.12. Display Backlight
2.13. Device Inquiry
2.14. Statistics
3. Display Interface
3.1. USB Display Interface Access
3.2. Display Interface Protocol
3.2.1. Frame Header
3.2.2. Pixel Data
3.2.3. Pixel Color Encoding
3.2.4. XORing Pixel Data
3.2.5. Frame Buffering
3.2.6. Allocating Libusb Transfers
4. Appendix A: MIDI Implementation Chart

I imagine this could inspire a whole lot of different people.

1. For the curious, you can learn how Push 2 works, just by browsing. (I had a manual to the Space Shuttle as a kid; this is sort of like that for hardware controller fans.)

2. If you’re working on a Max for Live patch, you can now easily learn how to make even minor modifications and hacks.

3. Developers working on Push 2 controller support now can do all kinds of new things.

4. People wanting to use Push 2 with hardware other than Live now can go about that in more powerful ways (and that’s possible, too, because all of this works regardless of OS and host).

5. People designing their own DIY hardware can learn from what Ableton have done. Yes, heck, that includes competitors – but to be honest, those competitors probably could figure this out on their own. And, oh, by the way, competitors will also be under equal pressure to reciprocate, which is good for all of us.

It’s not really “open source” – Ableton owns everything you see here. It wouldn’t really make sense to modify, anyway, as it’s tied specifically to the Push 2 hardware. It’s more like public source – but that’s still a good thing.

I think it’s all intensely healthy. I’d still like to see an API on the side of the Live software that makes it easier to make modifications. But this is indisputably good news.

And since I really have no idea what people will do with it, let us know what you do intend to do with it – or share the results.

  • aleytx

    Very nice, now we need official info on the python scripts..

    • Cesar Pantoja

      Indeed, official documentation for the Python API would be a welcomed addition.

  • chaircrusher

    It is relevant that the beta for the next minor release of Ableton Live is HEAVILY focused on improving Push behavior with that application….

  • newmodernscience

    I wish they’d add an easier way to add Swing like the Push has a knob for it. I kinda hate the groove pool workflow. Or a nice Max 4 Live patch that would add global swing or something.

    • You might help yourself w/ an arpeggiator device and it’s swing and timing option. Or maybe there’s a M4L device on the web if you own Suite.

      • newmodernscience

        That’s a good option, and there are devices like arps and step sequencers that do that, but i’d like to be able to do that globally like the Push does. To me, the Push is giving you a tactile experience for controlling Ableton. You can quickly record a sequence, loop it, quantize it, and then with the Push, you can turn the swing knob and dial in some swing (and then hit quantize to lock it in). You can more or less do this entire process without a Push, except for the swing. If you want swing, you have to go to the groove pool, and mess with all that, when it would be really nice to just have a global swing knob.

        • qsdfasdfwerreqwerwer

          push1 has swing knob. useless for me because i dont like generic swing….i’d rather the knob be for cue because i dont like holding shift adjust cue. (cue is prob my most turned knob in ableton)

  • thundercat

    come on Stray, time is now for a PXT General using Push 2! 🙂


  • Top Tier Ableton Customer !!!!

    I just want ableton to make the push 2 the best ableton midi controller, I don’t want to depend on third party developers for that. I didn’t pay almost a thousand dollars to depend on third party developers to do the heavy lifting, I want to see every common sense major improvement to push that a third party developer makes to push be done first by Ableton. I want Ableton to beat everybody to the punch when it comes to maintaining and improving a very expensive kick ass controller that they developed,and if one of the great third party developers comes out with a great idea and implements it then I want ableton to jump on it quickly and include something similar or better for all of the people who spent so much money for this controller !!!! and I paid good money for those desires to be considered reasonable. I want favoritism from ableton because I spent so much money on their controller and I want them to act like they know it!!!

    • wetterberg

      It sounds like you think they’re giving up internal development? If so, that’s a very strange assumption to make here. You *are* receiving favoritism from Ableton; not only did they put in the (massive!) amount of work to document your expensive controller, they’re of course still tweaking and expanding on its use.

      This isn’t an either/or situation. Third parties can work with this now *as well as Ableton*… that’s the whole point.

      • Top Tier Ableton Customer

        thanks for that, I have been watching third party devs move a little faster than ableton on this and admittedly it’s got me a bit worried. I do believe that ableton should be far ahead of everyone else in this regard… will have to see how it all pans out, thanks for your thoughts.

        • Man, have you’ve been watching the beta releases? They are putting in the very most user requested features version by version for free what other companies would put into new major versions. That way, the usability constantly evolves for the better.

        • PaulDavisTheFirst

          By documenting what Push 2 does, Ableton makes it possible to use Push 2 with other software, which has the potential for increasing sales of the device, which has the potential for making customers like you even happier by enabling other things to happen that otherwise would not.

    • Neil

      “I want, I want, I want…” Maybe you should try stamping and screaming. That might do it.

      • Top Tier Ableton Customer

        I’m happy to see that you can see that I am not ‘stomping and screaming’ so at least I know you’re not delusional.

        • Moon

          I want.

    • Agent Amsterdam
  • partofthepuzzle

    / modest rant mode on

    I find it curious and more than a little frustrating and annoying that Ableton has documented the API for Push while steadfastly refusing for years to document the Live API. Arghhh.

    Update: It occurred to me that I haven’t researched this recently and that maybe Ableton came though on the Live API documentation when I wasn’t looking. If so, kudos to them. If not Arggghhh x 10!

    P.S. Please, don’t talk to me about M4L! It’s NOT the same thing.

    / rant off, back to my happy music place 😉

    • I too would love to know about the Live API. Is there any documentation?

    • PaulDavisTheFirst

      Speaking as the author of a DAW’s internal API (Ardour), I’d like to point out that designing a hardware surface control protocol (particularly if it is already constrained to be MIDI) is a vastly simpler and mostly single-step process than defining the DAW API.

      With Ardour, we find it important be able to change up the API any time we feel like it, in order to enable new functionality, fix incorrect assumptions or just generally clean up code.

      As there are more and more users of the API, as is the case with Ableton, it becomes harder to treat the API as 100% dynamic, but I would imagine that their incentive to document it is pretty low, because as soon as you document it, you start either creating an ongoing documentation process or causing things to drift out of sync as the API changes over time.

      Robin Gareus recently added Lua support for Ardour’s internal API, and documenting that is going to be quite a problematic task for some time to come, for the reasons I’ve alluded to.