Ableton Forum

initial impressions...

case sensitivity sucks, all lower case works for me. In some cases it's 'Application' or 'application', eg "doc=Live.Application.get_application().get_document()"
Too much to remember. If I writing this code daily it would stick, but we're hobbyists.

I look forward to more source code looks, looks like it's in the works like this page Until then I'll read up at python.org and consider the connections.

The install docs says to put unzip the files into a SCRIPTS directory, it's kind of misleading, don't make a SCRIPTS directory, the
LiveTelnet
LiveOSC
simple_osc_client
folders go into the
Ableton\Live 6.0.7\Resources\MIDI Remote Scripts
Next to the dirs for the other possible devices that show up in Live under control surfaces. Make a dir there called "The Alan Parsons Project" and The Alan Parsons Project will show up as a control surface (but is totally worthless, that's just where Live gets the names of control surfaces).

It's pretty quick to check out, unzip the files like I wrote above, set up "Live Telnet" as a control surface, it just shows up as the directory should.
on windows hit START-cmd and type in
doc=Live.Application.get_application().get_document()
<enter>
doc.tempo = 80
and watch the tempo change in Live.

From there, in the Python shell window hit File and open
C:\Program Files\Ableton\Live 6.0.7\Resources\MIDI Remote Scripts\LiveTelnet\LiveTelnet.py
to see what the LiveTelnet command does
and check to see what Python commands are being used, the code is commented.
http://docs.python.org/ref/front.html
and start reading to see how it's implemented.

anyway, enough for a first night's look, my $0.02 on getting started...

Great feedback and noted Tone! We're still a young project but we're working fast and feedback like this helps us understand where the pain points are! Much thanks!

Tone Deft wrote:initial impressions...

case sensitivity sucks, all lower case works for me. In some cases it's 'Application' or 'application', eg "doc=Live.Application.get_application().get_document()"
Too much to remember. If I writing this code daily it would stick, but we're hobbyists.

that's the ultra longhand that it's worth knowing, but don't bother using , use getSong() instead.
EG:
getSong().tempo=44.4 is the same as
Live.Application.get_application().get_document().tempo=44.4

there's a whole bunch of handy code like this included, open liveUtils.py in the python IDE which is called IDLE . Have a look in your start menu (if you are on windows) open Idle and use it to open the liveUtils file in your \MIDI Remote Scripts folder.

read the functions there, and then try typing them. All save on typing.

Agree about the capitalization, but that's a python thing, so I guess then the request is "don't use any capitals in your coding" which isn't probably very realistic because I imagine that all this has to interface with a lot of pre-existing Ableton python code. (?)

In the same vein, things could be 'app' rather than 'application', etc. to save some typing. But I guess it's a trade off of readability vs keystrokes.

longjohns wrote:Agree about the capitalization, but that's a python thing, so I guess then the request is "don't use any capitals in your coding" which isn't probably very realistic because I imagine that all this has to interface with a lot of pre-existing Ableton python code. (?)

I blame windoze for making people case insensitive

you're right about it having to interface with the Ableton code (which is Boost.Python wrappers around C++) but the use of case often provides information about what you are dealing with. If a name is capitalised its most likely a module or a class, if its not then its something like a method or an attribute.

mind you i suppose python also exposes the down-side of case-sensitivity in non-compiled languages that means you dont find out until run-time.

i guess sometimes life's a bitch.

Angstrom wrote:that's the ultra longhand that it's worth knowing, but don't bother using , use getSong() instead.
EG:
getSong().tempo=44.4 is the same as
Live.Application.get_application().get_document().tempo=44.4

there's a whole bunch of handy code like this included, open liveUtils.py in the python IDE which is called IDLE . Have a look in your start menu (if you are on windows) open Idle and use it to open the liveUtils file in your \MIDI Remote Scripts folder.

read the functions there, and then try typing them. All save on typing.

Thanks, I'll check that out. I've used lots of other languages but have only read about object oriented coding, these days it's all VHDL/Verilog/C for me. Now I can finally get into a project to apply what I've read. I got a kick out of just making command line changes to the BPM.


Nathan - No worries on the early nature of the project, it's a great foundation and we all have day jobs, the python support will come with community and that thing called 'free time' (whatever that is.)

Tone Deft wrote: I got a kick out of just making command line changes to the BPM.

Indeed, my simple pleasure was

launchClip(0,0)

Angstrom wrote:

Tone Deft wrote: I got a kick out of just making command line changes to the BPM.

Indeed, my simple pleasure was

launchClip(0,0)

so damn simple...

It'll be amazing when we can compile a list of commands, get those building blocks together, sample code, tips n tricks. A year from now will be very interesting.

Osx API...

/had to be done.

I am *really* interested in this API ...
not interested at all in the free beer.
Nope, .... just API, no beer.

longjohns wrote:Agree about the capitalization, but that's a python thing, so I guess then the request is "don't use any capitals in your coding" which isn't probably very realistic because I imagine that all this has to interface with a lot of pre-existing Ableton python code. (?)

In the same vein, things could be 'app' rather than 'application', etc. to save some typing. But I guess it's a trade off of readability vs keystrokes.

You're far better off making things readable rather than saving a few keystrokes (within reason of course). Most editors for programming have macros that'll compete words for you (it's ctrl+p in vim for instance). You spend far less time writing the code in comparison to debugging it, so the easier it is to debug the better.

ohcrap, now i have to learn python aswell then.
man, and i was struggling with vvvv.

damn you guys.

Any advice re: vim vs. emacs? I dl'd emacs basically on the toss of a coin...

I suppose the best way to save keystrokes is by making appropriate new definitions, e.g. the getSong() example

longjohns wrote:Any advice re: vim vs. emacs? I dl'd emacs basically on the toss of a coin...

I suppose the best way to save keystrokes is by making appropriate new definitions, e.g. the getSong() example

This is one of the oldest debates in the UNIX world, where they both hail from...

Emacs will be most 'familiar' to you, as it works a lot more like the text editors you're used to than vim does. Vim is a 'modal' editor, ie. it has several modes for editing. The basic mode is search mode, where you can skip about yer text on a per-character, per-word, per-line basis, search and what have you. To enter text, you go into insert mode by pressing a key (the i), and then you can just write. It feels a bit weird at first, but once you start climbing the learning curve I reckon it pays off.

I don't remember if you're on windows or mac? I don't know the windows scene, but on Mac you might want to check out Smultron, TextMate and TextWrangler for nice editors that also do syntax highlighting and other helpful things. I'm sure there are loads for windows, too, but I don't know the names..

/Niklas