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

[Tone Deft]

The monome uses an FTDI USB interface chip, which uses the standard windows drivers, if that helps. I don't own one yet but it seems they're fairly plug and play. Thanks for closing the loop with them.

If 'standard windows drivers' == MIDI device, then yes. Monome will work fine with a MIDI Remote Script.

I got a clear answer from the monome site

posted by steveduda (steveduda)
on 06.06.2007 21:00

OSC doesn't "directly" communicate with the monomes, rather indirectly
via Applications like SerialIO (and similar apps, i.e. SerialXP,
MonomeSerial).
These apps handle the translation to/from OSC(or MIDI) <->
Serial(Monome).

There isn't an official published set of OSC commands (AFAIK) for the
Monome, this is something I've meant to ask for myself, but it is
something flexible potentially (really, it all depends on what messages
the OSC<->Serial app, e.g. serialIO etc has implemented).

the messages I've seen mentioned are as follows:

OSC Out:
/box/press

OSC IN:
/box/led
/box/led_col
/box/led_row
/box/alloff (same as /box/clear I assume)
/box/intensity
/box/shutdown
/box/test

In my OSC implementation (monochrome vst), besides box/clear on startup
(to quickly blank all 64 LED's), I only use the two "most important"
messages (/box/press and /box/led) which both have 3 ints following
(x,y,bool state)

e.g. "/box/led 0 0 1" (enables top-left LED)


hope this helps!
Steve

It's not straight up OSC but the helper apps are in place.

[Bassic Dave]

how is this useful to people that dont have controllers that need OSC or clip names etc?

I have a clunky old UC33e and that's all

is there any big fun thing you can do with it that I couldnt before?

This is my question too. Something in my gut tells me this is really really good, but i cant see what i could to with osc or any of this that i couldnt do with standard midi. I know im missing something, live being open source has to give us something extra special, i just cant see what.

Can anyone give an explanation for those of us that dont get it yet?

Thanks in advance! =]

[Nathan Ramella]

hope this helps!
Steve

Yep, this would easily fit right in, here's how:

1. Add callback for /box/press x y bool, x/y being track/clip matrix

2. In your callback for /box/press you could include an OSC outgoing message to the monome for the /box/led stuff to get feedback on current state.

That's it. If you wanted to be super badass you could attach listener methods onto the clips in the tracks (this is slightly more complex), but every time the state of a clip playing or stopping play occurs it could automatically send out an osc /box/led x,y,bool to the monome.

Given the code we've provided, a little Python knowledge could make this happen in an afternoon.

[Nathan Ramella]

how is this useful to people that dont have controllers that need OSC or clip names etc?

I have a clunky old UC33e and that's all

is there any big fun thing you can do with it that I couldnt before?

This is my question too. Something in my gut tells me this is really really good, but i cant see what i could to with osc or any of this that i couldnt do with standard midi. I know im missing something, live being open source has to give us something extra special, i just cant see what.

Can anyone give an explanation for those of us that dont get it yet?

Thanks in advance! =]

1A MIDI can only send 2 bytes per 'payload'.

1B OSC can send arbitrary blobs, floats, ints, strings -- as well as arrays of those values. Want to trigger track 0, sample 5? Use address /ableton/clip
and send it values (0,5).

2A MIDI has a limited set of 'addresses'. It can send to 16 "channels", and within those 16 channels a pretty small subset of paths, CC, Note-on/Note-off,Sysex, etc.

2B OSC has an open-ended addressing system that you can direct any message to any callbacks you wish.

3A MIDI is primarily a wire-based protocol, some wireless solutions exist, to the best of my knowledge all are proprietary, none are standard.

3B OSC can be used over UDP or TCP to allow applications to speak over a network. It's got a published spec and uses network protocols that virtually every desktop in the world (and space) use. Imagine you're performing for people with Live and you want to engage your audience. You could publish 'participant' OSC addresses and allow devices to modify those settings (within specified ranges), or you could tie envelopes or device settings to lighting, or video triggers, or cellphones speaking bluetooth, or PSPs, or microphones, or ... etc etc. Sure, you can do that with midi, but it'd probably take a little soldering or a lot of glue code.

The trick here is to detach yourself from thinking MIDI, think combos, think interactions, think progressive organic behavior that you have control over using an object oriented language rather than being limited to 'on/off' of a note or 1-127 on a CC.

And finally, OSC isn't really 'the big deal' about LiveAPi, the Python API access is. It's basically an example of how powerful this interface can be, we shimmed in a network transport layer interface to allow remote control. Just imagine what you'll be able to do.

On the ho-hum side of things, you could recolor your clips automatically if you wanted. All bass immediately becomes green, all leads red, etc. You could do name matching on that type of stuff. Or, you could 'tie' knobs together.. Turn a dial from 1-127, another dial goes from 127-1 inversely. If that kind of stuff doesn't turn you on and you don't do performance stuff, then this probably isn't a big deal for you -- yet.

I've been dreaming up ideas since the release that have nothing to do with playing music, but are more about automating processes within Ableton to save me time.. But that's just what _I_ want. You've got the power to make what _you_ want.

That's the big deal.

Once this post-release rush of communication and documentation is over we'll have some examples that'll blow your sox off. Right now I can understand how it's only the gear-heads getting excited, but pretty soon you're going to be seeing a lot of practical applications that'll get the average user excited!

-Nate

[Tone Deft]

Once this post-release rush of communication and documentation is over we'll have some examples that'll blow your sox off.

GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME GIMME


And where the f-ing hell is Machinate?????

I'm not sure what will happen but given the skins, racks, patches and other stuff users have shared, this voodoo will grow in time.4

Needless to say a proper step sequencer is an obvious first project. What can we do with graphics?

First dinner, then I dig into this.

[forge]

Or, you could 'tie' knobs together.. Turn a dial from 1-127, another dial goes from 127-1 inversely. If that kind of stuff doesn't turn you on and you don't do performance stuff, then this probably isn't a big deal for you -- yet.

you cn do that in Live 6 now

[forge]

Needless to say a proper step sequencer is an obvious first project. .

you can imagine a way of making a step sequencer with this??

[forge]

And where the f-ing hell is Machinate?????

.

He's playing with his new Evolver

[Tone Deft]

Needless to say a proper step sequencer is an obvious first project. .

you can imagine a way of making a step sequencer with this??

I know ZERO python scripting but you can monitor when a button is pushed, one button per step. And you can tell Live when to fire a clip. Maybe a 16 track wide set with blank buttons, monitor those buttons for pushes to turn steps on/off. Then you play back each step in time. It seems you can monitor BPM to divide up the time and set a counter to delay from step to step. I'm sure there are visual hooks into Live too. ACTUALLY that would be a great way to use 2 instances of Live at once, one acts as some kind of instrument (monitor button pushes, give visual feedback) the other would receive commands from the script to launch clips at the right time.

[longjohns]

I thought he got a jizzob

[Tone Deft]

And where the f-ing hell is Machinate?????

.

He's playing with his new Evolver

Damn you Dave Smith.

[ahlstrominfo]

Eagerly waiting for an OSX version. Then I probably can code my own MLR/monome in python. It'll be nasty.

[Bassic Dave]

how is this useful to people that dont have controllers that need OSC or clip names etc?

I have a clunky old UC33e and that's all

is there any big fun thing you can do with it that I couldnt before?

This is my question too. Something in my gut tells me this is really really good, but i cant see what i could to with osc or any of this that i couldnt do with standard midi. I know im missing something, live being open source has to give us something extra special, i just cant see what.

Can anyone give an explanation for those of us that dont get it yet?

Thanks in advance! =]

1A MIDI can only send 2 bytes per 'payload'.

1B OSC can send arbitrary blobs, floats, ints, strings -- as well as arrays of those values. Want to trigger track 0, sample 5? Use address /ableton/clip
and send it values (0,5).

2A MIDI has a limited set of 'addresses'. It can send to 16 "channels", and within those 16 channels a pretty small subset of paths, CC, Note-on/Note-off,Sysex, etc.

2B OSC has an open-ended addressing system that you can direct any message to any callbacks you wish.

3A MIDI is primarily a wire-based protocol, some wireless solutions exist, to the best of my knowledge all are proprietary, none are standard.

3B OSC can be used over UDP or TCP to allow applications to speak over a network. It's got a published spec and uses network protocols that virtually every desktop in the world (and space) use. Imagine you're performing for people with Live and you want to engage your audience. You could publish 'participant' OSC addresses and allow devices to modify those settings (within specified ranges), or you could tie envelopes or device settings to lighting, or video triggers, or cellphones speaking bluetooth, or PSPs, or microphones, or ... etc etc. Sure, you can do that with midi, but it'd probably take a little soldering or a lot of glue code.

The trick here is to detach yourself from thinking MIDI, think combos, think interactions, think progressive organic behavior that you have control over using an object oriented language rather than being limited to 'on/off' of a note or 1-127 on a CC.

And finally, OSC isn't really 'the big deal' about LiveAPi, the Python API access is. It's basically an example of how powerful this interface can be, we shimmed in a network transport layer interface to allow remote control. Just imagine what you'll be able to do.

On the ho-hum side of things, you could recolor your clips automatically if you wanted. All bass immediately becomes green, all leads red, etc. You could do name matching on that type of stuff. Or, you could 'tie' knobs together.. Turn a dial from 1-127, another dial goes from 127-1 inversely. If that kind of stuff doesn't turn you on and you don't do performance stuff, then this probably isn't a big deal for you -- yet.

I've been dreaming up ideas since the release that have nothing to do with playing music, but are more about automating processes within Ableton to save me time.. But that's just what _I_ want. You've got the power to make what _you_ want.

That's the big deal.

Once this post-release rush of communication and documentation is over we'll have some examples that'll blow your sox off. Right now I can understand how it's only the gear-heads getting excited, but pretty soon you're going to be seeing a lot of practical applications that'll get the average user excited!

-Nate

Thanks for the reply, ill be downloading it tonight and reading about python. I see something big coming in electronic music with innovative devices like lemur and monome and now this. I think its coming to the point where everyone can have their own custom music machines, molded to their workflow and style, with the integration flowing from custom controllers to custom software. I can also see this really accelerating the evolution of electronic music as a performance. We all have to agree that a rock band can be much more interesting to look at than a guy with some equipment, but throw in custom controllers with all kinds of blinking lights and displays that no one else has and super efficient and flexible software and the sky is the limit.

Sorry for the rant.

D.

[stjohn]

Nathan you are the man!!! i cant wait to get into the different programmable areas!! This shit is here to stay!! Fabadooby!

btw, i was confused by this bit..u might want to change the wording

To install, first make sure you have installed
Python 2.2.x in c:\Python22 (we use some of it's modules which are not included
in Ableton's version). Next place all this directory inside the MIDI Remote
Scripts directory of Ableton:

i get that the second bit is referring to the folder that he .py files are in...but it might be overlooked by gobshites like me !!



thanks again mate! Legend!!

[Nathan Ramella]

btw, i was confused by this bit..u might want to change the wording

To install, first make sure you have installed
Python 2.2.x in c:\Python22 (we use some of it's modules which are not included
in Ableton's version). Next place all this directory inside the MIDI Remote
Scripts directory of Ableton:

Whoops, ok. I've been typing faster than I've been thinking. I'm working on improving the faq section right now, so again -- thanks to everyone for their great questions. The writers block @ 4am is now replaced with clear thought!