Who wants access to Ableton's Python API? .. You? .. Ok!

queglay · Post by **queglay** » Mon Feb 04, 2008 3:16 am

so what happenned to the live api stuff here? i wouldn't mind being able to read that faq page on the liveapi.org site. why did it get taken down?

hope people are still into this...

Angstrom · Post by **Angstrom** » Mon Feb 04, 2008 3:34 am

The site got hacked so it now lives in a slightly reduced form at

http://code.google.com/p/liveapi/

I've not done anything with it recently, although I have lots of ideas.
Lack of time mainly.

queglay · Post by **queglay** » Mon Feb 04, 2008 3:54 am

thanks for the reply. i managed to get a hold of everything i could of your google forum. though i couldn't find that faq. is it available anywhere? or through email?

thanks angstrom

Angstrom · Post by **Angstrom** » Mon Feb 04, 2008 4:12 am

oh it ain't me your after, it's a guy by the name of Nathan I think.
Nathan Ramella was the LiveAPI guy

he is on this forum as a member, but I think these days he is busy with work or life, or something similar.

queglay · Post by **queglay** » Mon Feb 04, 2008 4:59 am

i can't get the livetelnet control surface option to work - i get a runtime c++ error in live 6.0.10

im running python 2.2.3 as instructed

liveosc seems to work fine though (in the control surfaces menu) without crashing

i tried getting something working with live osc in the meantime. i executed the sample osc script and i could see it was sending a string out (because i checked it with max/msp, but ableton didn't respond in anyway to the osc messages being sent.

I was wondering where i am supposed to copy the _LiveAPICore directory to.

thanks again guys. im happy to share whatever i manage to solve here, though much of it may end up being done in max/msp.

queglay · Post by **queglay** » Mon Feb 04, 2008 6:39 am

i wondered if might have something to do with this line in liveosc.py-

self.oscServer = RemixNet.OSCServer('192.168.200.69')

tried setting it to my local ip but didn't help.

queglay · Post by **queglay** » Mon Feb 04, 2008 10:49 am

OK i have figured from a debug script that it was not able to find the module _LiveAPIcore, and so generated the runtime c error.

now there are afew few references to this in the liveosc and livetelnet directories as -
from _LiveAPIcore import *
and
from _LiveAPIcore import LiveUtils

the thing that gets me is _LiveAPIcore is a directory, not a module. so how can you import from a directory as if it were a module? have i simply put the _LiveAPIcore folder in the wrong place?

mdk · Post by **mdk** » Mon Feb 04, 2008 11:09 am

if you read here :

http://docs.python.org/tut/node8.html

that explains about python modules and packages.

particularly :

modules are searched in the list of directories given by the variable sys.path which is initialized from the directory containing the input script (or the current directory), PYTHONPATH and the installation-dependent default

If the Midi Remote Scripts folder is in sys.path it will use the folders available there. if not then it wont find it.

what does sys.path say?

queglay · Post by **queglay** » Mon Feb 04, 2008 11:23 am

hehe, its funny i just found this document -
if you look at packages-
http://docs.python.org/tut/node8.html#S ... 0000000000

but the thing is it will only treat directories like this if they have a __init__.pyc file in them, and the _LiveAPICore doesn't have this file. i know i can just create it, but i wonder if this was what was intended.

so i went ahead and tried it anyway, and added the _LiveAPICore directory to the python22/lib folder as this is a system path.

the good news is the crashing disapeared. but i still get this error log generated, which is a new set of problems -

starting stderr logstarting stdout logTraceback (most recent call last):
File "C:\Program Files\Ableton\Live 6.0.10\Resources\MIDI Remote Scripts\LiveOSC\__init__.py", line 34, in create_instance
return LiveOSC(c_instance)
File "C:\Program Files\Ableton\Live 6.0.10\Resources\MIDI Remote Scripts\LiveOSC\LiveOSC.py", line 43, in __init__
self.oscServer = RemixNet.OSCServer('192.168.200.69')
NameError: global name 'RemixNet' is not defined
Traceback (most recent call last):
File "C:\Program Files\Ableton\Live 6.0.10\Resources\MIDI Remote Scripts\LiveOSC\__init__.py", line 34, in create_instance
return LiveOSC(c_instance)
File "C:\Program Files\Ableton\Live 6.0.10\Resources\MIDI Remote Scripts\LiveOSC\LiveOSC.py", line 43, in __init__
self.oscServer = RemixNet.OSCServer('192.168.200.69')
NameError: global name 'RemixNet' is not defined

mdk · Post by **mdk** » Mon Feb 04, 2008 11:30 am

i was going to suggest creating the __init__.py file.

anyway, at least you know a new problem means youre making progress

the error says it cant find RemixNet which is in _LiveAPIcore, so it seems like the import doesnt actually bring in the names.

i reckon try adding the __init__.py and stick _LiveAPIcore back in the remote scripts folder.

see what happens

queglay · Post by **queglay** » Mon Feb 04, 2008 12:44 pm

where ever i found

from _LiveAPICore import *

in any .py file i replaced it with this

from _LiveAPICore import RemixNet
from _LiveAPICore import OSC
from _LiveAPICore import LiveUtils

anything else that refered to from _LiveAPICore i replaced with a direct reference

i also replaced the ip adress in the liveosc.py file with my own ip.

if there is a better way to do this let me know. im sure i have overlooked something basic that just isn't covered in the documentation.

i can now send osc messages to ableton and can succesfuly rename clips, fire them off
and do whatever.
i can also retrieve some osc messages in max/msp, however it only seems to work when
integers or floats are sent out from ableton to max/msp.

text strings so far a no go.

but so far im happy. man its a dream come true to seem those max wires actually do something in ableton.

queglay · Post by **queglay** » Mon Feb 04, 2008 12:53 pm

yeah just checked, if any text string is sent via osc, nothing gets sent at all out of ableton. not sure where to look now, but ill delve into the osc python scripts when i next get a chance.

mdk · Post by **mdk** » Mon Feb 04, 2008 1:11 pm

what message are you sending?

i never touched the LiveAPI OSC stuff before but im writing an OSC related app at the moment so im in the OSC headspace

queglay · Post by **queglay** » Mon Feb 04, 2008 1:57 pm

well if i send any message that returns a int or float back such as
/live/tempo
or
/live/time

then ableton correctly send that value right back at me.
anything like this-
/live/name/clip
or
/live/name/scene
which as documented should send back all the 2D clip locations and labels. but it sends nothing back.

i checked the code in the liveutil.py doc, and when i removed the string variable from the osc argument, i succesffuly retrieved all the 2d clip locations. so theres gotta be something wrong in how the osc module is sending strings.

mdk · Post by **mdk** » Mon Feb 04, 2008 2:56 pm

right, well from a quick look there is a bug in LiveOSCCallbacks.py for requesting a clip name, but it shouldnt stop it sending strings.

on line 258 my version says this :

self.oscServer.sendOSC("/live/name/scene", (trackNumber, clipNumber, LiveUtils.getClip(trackNumber, clipNumber).name))

but should be

self.oscServer.sendOSC("/live/name/clip", (trackNumber, clipNumber, LiveUtils.getClip(trackNumber, clipNumber).name))

looks like someone copy / pasted and forgot to edit the code properly

what i would suggest is to first try replacing the

LiveUtils.getClip(trackNumber, clipNumber).name)

with a string literal in the python code (say "test") to see if that comes out properly. If it does then there is something wrong with the LiveUtils.getClip lookup, if it doesnt then there is something wrong with the message sending.

The oscServer.sendOSC just delegates to the oscClient code (this is in RemixNet.py)

so the block in OSCClient.send starting at line 132 (in the version i have) does the type checking, so try putting some debug code in there and see what types python thinks its getting.

you might want to dig down into OSCArgument (OSC.py line 165) which is where the message arguments get converted to binary. This particular line looks like fun :

OSCstringLength = math.ceil((len(next)+1) / 4.0) * 4

add 1 to the length of the string, divide by 4, take the ceil and multiply by 4. ?

Looks like some kind of padding calculation for alignment on 4-byte boundaries.

The string is then packed into a double char format here

binary = struct.pack(">%ds" % (OSCstringLength), next)

right so the OSC Spec says this :

OSC-string

A sequence of non-null ASCII characters followed by a null, followed by 0-3 additional null characters to make the total number of bits a multiple of 32.

which is why the 4 byte alignment calculation is done.

anyway, that looks like the lowest level string handling code so you could always start at the bottom and tracing out what its actually working with.