No -- The screen API for the Push 2 is very low level, which means a ridiculous amount of work to support it. It makes much more sense for me to support a controller that I actually, umm, have some control over...

No -- The screen API for the Push 2 is very low level, which means a ridiculous amount of work to support it. It makes much more sense for me to support a controller that I actually, umm, have some control over...

No -- The screen API for the Push 2 is very low level, which means a ridiculous amount of work to support it. It makes much more sense for me to support a controller that I actually, umm, have some control over...

Cheers,
Jim

perhaps, I can repeat my request for a controller api...

this would allow open source development for specific controllers, and also perhaps provide some other interesting integration options.

this is the route most daws, Live, Bitwig, Reaper etc.. have gone, due to the huge number of controllers being released and their very different interfaces.

theres quite a number of open source scripting languages available you could integrate, so that the development effort (for you) is interfacing this to your object model. (javascript for some reason seems to be the popular one)

I went through that thought process a while back, while may make sense for some other companies, it is not a path I am interested in.

The work of designing the API, building, testing, maintaining and supporting it is pretty extensive, and gets significantly more complicated when I need to re-factor things internally. So there’s a very big cost there in terms of having it at all -- and a very high risk, if I publish an API and then have to change it later.

But there's also a more subtle reason: I take great effort when creating support for a new controller to make sure that it fits with the Numerology workflow in a natural manner. And the process of making those design decisions -- of finding a way to get maxium use out of a grid or a keyboard with a few knobs -- has a huge beneficial impact on the design of the Numerology UI -- It makes me constantly re-evaluate: "Is this simple enough? Could this be better?". If I stopped doing all that and just said: "Here's the Object API, go for it", then I've lost that opportunity.

I have a push 2 and it seems like it's mostly all working. So if you have a Push 2 already or want one to control Ableton, it surely makes sense to use it rather than a launchpad as well right? Obviously having a functioning screen would be cool but the Launchpad doesn't have that anyway.

I think the message this site/forum gives with regard to Push 2 support is a bit confusing. It would probably be useful to say you support basic functionality but not the screen. For a potentially buyer, the impression is that it's not supported at all and it appears quite usable.

Would you say that you will continue to maintain this basic functionality for the Push2?

Probably worth also pointing out more clearly that the Device, Browse and Arrows need to be used instead of the top row like the launchpad.