PUSH IT REAL GOOD

[metastatik]

“Open platform” and “open source” are two very different things. Live is an open platform in that MIDI Remote Scripts and M4L devices can be created to modify the functionality of Live and the way in which MIDI devices interact with Live. This is easily seen in scripts like ClyphX, the Maschine script for Live and touchAble. None of these were developed by Ableton, they were developed by 3rd parties using an API created by Ableton. If Live were a closed platform (like Maschine), scripts of this sort wouldn’t be possible.

Also, “reverse engineering” and “decompiling” are two very different things. No one has (or would need to) reverse engineer Push’s script to enable it to be modified. The script simply needs to be decompiled, which is easily done. This is one of the benefits of Ableton’s choice to use the Python programming language for MIDI Remote Scripts. Python is one of the easiest modern languages to learn, read and decompile.

In terms of documentation, Live’s _Framework for creating MIDI Remote Scripts is documented where necessary, but most of the source is self-documenting. Again, this is one of the benefits of Python. Python source code reads a lot like English.

Lastly, although Ableton allows for the creation of MIDI Remote Scripts, it’s not something they support for obvious reasons. So it makes sense that they don’t provide source code or non-programmer friendly documentation. M4L is a bit of a different story and I agree that better documentation is in order there.

[lo.key]

humnumb, theres a big difference between closed and undocumented. Push, and live, are open environments in that much of their functionality is exposed to manipulation. I'll grant you they have done a deplorable job in documenting the specifics of that interaction, but that doesnt mean that it doesnt exist. It's hardly a 'closed platform'.

[cyclicAMP]

In terms of documentation for Live's _Framework API, a simple search and I found this:

Ableton 9?s Python Framework Documentation Available!
http://midicontrolfreaks.com/_Framework_901/

compliments of midicontrolfreaks.com

I think the Ableton community really rocks it!

[halblaine]

^ What are the implications of having that framework documentation?

Does this + decompiled code mean that the Push is essentially open for swashbuckling?

[lo.key]

oh yes. The github for the python scripts is linked on juliens blog. http://julienbayle.net/ableton-live-9-m ... e-scripts/

and there has already been a nice hack to the step sequencer (allowing the push to recognize a drumrack nested within an instrument rack, and allowing pressure data to be input directly to the steps of the sequencer). http://viewtopic.php?f=1&t=191287

the colours and the scales are particularly easy to change around.

But the docs on the m4l side of things (in terms of the control_surface behaviour) are still absent, as far as i can tell. I know ableton doesnt want people playing too heavily with the python api (as this is fairly low level), but the m4l api end of things would really benefit from more example patches and documentation, imo.

[BobTheDog]

but the m4l api end of things would really benefit from more example patches and documentation, imo.

Is there any at all?

I can't seem to find anything.

[metastatik]

and there has already been a nice hack to the step sequencer (allowing the push to recognize a drumrack nested within an instrument rack, and allowing pressure data to be input directly to the steps of the sequencer). http://viewtopic.php?f=1&t=191287

That’s not a valid link, but these modifications are available at my forum. Also my ClyphX script has some actions related to Push for doing things like forcing instrument mode to be used on Drum Rack so you have more pads to use for playing and for changing scale settings so that scales can be changed automatically at different points in your set. All of this has been done without my having Push on hand. I’ll finally be receiving Push tomorrow and can get into some more serious modifications.

As an aside, the Push script and (to a lesser extent) the _Framework changes with each release, so those interested in modifying things should have methods for decompiling and generating docs for themselves. Uncompyle2 is a good decompiler and there are several tools (like Epydoc) for generating docs. It’s also handy to have docs on Live’s API on hand. This script makes that very easy.

[lo.key]

thanks metastatik, teach me to try and post links via my phone.

You're doing good work amigo, cheers!

[halblaine]

[humnumb]

humnumb, theres a big difference between closed and undocumented. Push, and live, are open environments in that much of their functionality is exposed to manipulation. I'll grant you they have done a deplorable job in documenting the specifics of that interaction, but that doesnt mean that it doesnt exist. It's hardly a 'closed platform'.

Sure, the exposing of Live's API via Max is great although it's not as easy as the userconfiguration texts. But Ableton decided to make hardware integration a commercial product, rather than it being a readily accessible feature by obfuscating the surrounding features like the session matrix, where a user has to buy some hardware or find the time to learn python and hunt down unofficial decompiles, if it wasn't for Julien Bayle for providing all of the recent scripts as .py files. Not only that, unofficial 3rd party decompiling is explicitly prohibited by Ableton's license agreement.

All the new APC functions since Live 8 and stuff like the clip launch box that were added to the remote control scripts and even Push's python step sequencer, scale grids etc. could have been documented and made available for us all through user configuration scripts but that isn't what has happened. Instead new bits of hardware are introduced that act as dongles for these API calls. Eventually someone decompiles the remote scripts from their pyc encryption and then the more adept computer programmers get on with the task of hacking the object model because Ableton doesn't document it at all. Max for Live has objects to address remote scripts but there are very few official tutorials on their use. In this vacuum of information individuals like Stray step in. The whole reason that the NativeKontrol ClyphX family of products exists is because Ableton have decided not to enable their own customers... preferring instead to fund a microindustry of coders and looppack retailers. It doesn't have to be like this, Ableton could just have carried on improving the user configuration text file system that they started with Live 6, or they could have provided Renoise style support for scripting. It's a really mediocre commercial solution.

[lo.key]

and its a beautiful thing ;D