LiveAPI : new google group

mdk · Post by **mdk** » Mon Mar 10, 2008 11:20 am

julienb wrote:I have another question/idea:
is it possible to create a script (*.py) to give all the possibilities given by LiveAPI (clip or not in a slot, type of clip why not, looped clip or not) and to provide it for max, for other hardware etc?

sure.

julienb · Post by **julienb** » Mon Mar 10, 2008 11:25 am

ok mdk!
I'll have time to re-dive in LiveAPI this week

if the concept is:
all LiveAPI methods/attributes are available to create our own scripts

then:
ALL is possible.

on my future deck (only grid triggering buttons) I'd like to have informations about presence of a clip but "nature" of the clip (looped or not, midi or audio etc)

let's go to code ..?!

hoffman2k · Post by **hoffman2k** » Mon Mar 10, 2008 11:40 am

mdk wrote:
hoffman2k wrote: 2 = Slot contains Clip
3 = Slot does not contain Clip

These values would be sent out when you load a Live set or when you add/remove a Clip from a Clip Slot.

This way all Live users could get the same functionality that Monolake has with the Clip Trigger Grid on the Monodeck 2. Without having to resort to having to hack the API with python.
Im 99% sure thats possible on both osx and pc. I'll have a go at something later today and let you know how I get on.

Awesome

julienb · Post by **julienb** » Mon Mar 10, 2008 11:43 am

mdk, do you think about Max to control deck leds or directly from Live remote scripts to the deck?

mdk · Post by **mdk** » Mon Mar 10, 2008 11:48 am

julienb wrote:mdk, do you think about Max to control deck leds or directly from Live remote scripts to the deck?

I suppose it depends on where you want flexibility and what you want to do.

If you push everything into the python code then if you want to change something then you have to write some code, copy it into the scripts directory and hope it doesnt crash.

if you use the code as just a data bridge between Live and Max then you have flexibility in max of how to handle that data from there.

Also you can prototype the device in max so you dont need actual hardware while developing. The big advantage here is that changing a max patch is a lot easier than rebuilding a hardware controller

hoffman2k · Post by **hoffman2k** » Mon Mar 10, 2008 12:11 pm

Plus, it'll be easier to do a preset system in max to support multiple controllers.

friend_kami · Post by **friend_kami** » Mon Mar 10, 2008 12:37 pm

wah, i thought the liveapi thing was dead. way to go!
now, let me just get some coffee and a brain to boot *cough*

frahnque · Post by **frahnque** » Mon Mar 10, 2008 2:13 pm

mdk wrote:
hoffman2k wrote: 2 = Slot contains Clip
3 = Slot does not contain Clip

These values would be sent out when you load a Live set or when you add/remove a Clip from a Clip Slot.

This way all Live users could get the same functionality that Monolake has with the Clip Trigger Grid on the Monodeck 2. Without having to resort to having to hack the API with python.
Im 99% sure thats possible on both osx and pc. I'll have a go at something later today and let you know how I get on.

Have you been able to install Python 2.2 on an OSX machine yet?

hoffman2k · Post by **hoffman2k** » Mon Mar 10, 2008 2:19 pm

frahnque wrote:
mdk wrote:
hoffman2k wrote: 2 = Slot contains Clip
3 = Slot does not contain Clip

These values would be sent out when you load a Live set or when you add/remove a Clip from a Clip Slot.

This way all Live users could get the same functionality that Monolake has with the Clip Trigger Grid on the Monodeck 2. Without having to resort to having to hack the API with python.
Im 99% sure thats possible on both osx and pc. I'll have a go at something later today and let you know how I get on.
Have you been able to install Python 2.2 on an OSX machine yet?

I think so. Wouldn't know how to run a version check though. I removed 2.5 and dug up 2.2. from the nets and then installed it.

hoffman2k · Post by **hoffman2k** » Mon Mar 10, 2008 2:20 pm

Btw, could this be of any use to you guys? Released about 4 days ago.

net.loadbang.jython is a package which supports the Python scripting/programming language within MXJ for Max/MSP.
We use the Jython interpreter, which allows Python and Java to interact, and gives Python access to the standard Java libraries (as well as any other Java code available to MXJ).

http://www.loadbang.net/space/Software/ ... ang.jython

frahnque · Post by **frahnque** » Mon Mar 10, 2008 2:48 pm

hoffman2k wrote:Btw, could this be of any use to you guys? Released about 4 days ago.

net.loadbang.jython is a package which supports the Python scripting/programming language within MXJ for Max/MSP.
We use the Jython interpreter, which allows Python and Java to interact, and gives Python access to the standard Java libraries (as well as any other Java code available to MXJ).
http://www.loadbang.net/space/Software/ ... ang.jython

In the sense of writing stuff in Python directly for Ableton Live, I'd say no. In the sense of ridding ourselves from Java syntax in the case of writing scripts for Max / MSP - absolutely. And I'll give it a go once I have less to do at uni.

Thanks for the heads up!

mdk · Post by **mdk** » Mon Mar 10, 2008 2:51 pm

frahnque wrote:In the sense of writing stuff in Python directly for Ableton Live, I'd say no. In the sense of ridding ourselves from Java syntax in the case of writing scripts for Max / MSP - absolutely.

haha. I like Java, although you have to have a nice IDE so you dont spend all day typing

frahnque · Post by **frahnque** » Mon Mar 10, 2008 4:51 pm

mdk wrote:
frahnque wrote:In the sense of writing stuff in Python directly for Ableton Live, I'd say no. In the sense of ridding ourselves from Java syntax in the case of writing scripts for Max / MSP - absolutely.
haha. I like Java, although you have to have a nice IDE so you dont spend all day typing

Truer words have never been spoken! The worst part of going to uni and discovering PL's like Ruby and Python is that you know there's just a tiny slim chance of programming them when your done - outside of Uni it's all about Java or C# these days...

regarding version check on Python - type "python -V" (note the capitalised V) and you'll be set.

How the heck did you get the damned thing to compile. After running ./configure and doing make it was all errors and no fun. The whole Darwin port thin didn't work either. I'm on OS X 10.5 if that matters.

julienb · Post by **julienb** » Mon Mar 10, 2008 5:01 pm

mdk wrote:
julienb wrote:mdk, do you think about Max to control deck leds or directly from Live remote scripts to the deck?
I suppose it depends on where you want flexibility and what you want to do.

If you push everything into the python code then if you want to change something then you have to write some code, copy it into the scripts directory and hope it doesnt crash.

if you use the code as just a data bridge between Live and Max then you have flexibility in max of how to handle that data from there.

Also you can prototype the device in max so you dont need actual hardware while developing. The big advantage here is that changing a max patch is a lot easier than rebuilding a hardware controller

I agree 100%...
I'd like to prototype the machine before any soldering actions (Hum! I never soldered anything!)

we have to write & work in your google groups!
union = power !

mdk · Post by **mdk** » Mon Mar 10, 2008 5:24 pm

frahnque wrote:How the heck did you get the damned thing to compile. After running ./configure and doing make it was all errors and no fun. The whole Darwin port thin didn't work either. I'm on OS X 10.5 if that matters.

Im on 10.4 (ppc)

MacPorts wouldnt install at first untill i re-installed the XCode tools, then it hadnt created the necessary shell settings (.profile) so the 'port' command wasnt on my path. So i added that manually then tried to install python22, at which point it couldnt find the .tgz archive from any of the locations, so I downloaded it manually, stuck it here :

/opt/local/var/macports/distfiles/python22/Python-2.2.3.tgz

because i noticed that was where the port install command was checking for an existing package file.

after that it compiled and installed.

not exactly user friendly

anyway, i've been doing some digging and so far no luck with getting the socket library to work, im rapidly coming to the conclusion that the python embedded in Live OSX is compiled *without* support for dynamic loading, i.e. no way of using binary (.so) libraries.

This exchange of emails

http://mail.python.org/pipermail/python ... 05710.html

seems to suggest that a static build of python *cant* support dynamic loading, at least on OSX. The problem seems to be that because OSX comes with python then embedding a build of python that supports dynamic loading would have problems co-existing with the system python. Of course windows doesnt come with python so I reckon thats why it doesnt face the same problems.

It would be nice if one of the ableton engineers could let us know what the exact situation is, but i suspect that is unlikely for one reason or another.

anyway, all is not lost, I can still imagine a cunning scheme involving midi where the incoming protocol (i.e. what goes into live) is note / cc based and the outgoing data is some combination of midi / cc / sysex.

AFAICT you can get sysex data into live but there doesnt seem to be the same restrictions on outgoing data from the python code so we can pump stuff out in sysex messages. Its not pretty, but it should work