nunja

I tried by a lot of ways to control the live set at high priority without success.

I am in a project that requires to control Ableton's transport (tempo / position / play / pause) with a relatively high time accuracy. I need to set some live_set properties at a rates below 10 ms, in a timely accurate way.

- pretty slow (if I send more than 1 event per 20ms, it starts to queue events)

- tied to the undo history (can you imagine that with 50 actions per /sec )

- polluted by everything that happens in the UI thread

live.remote was my second hope, but nothing except DeviceParametter is reachable. No possibilities to set properties and call functions from there. strange design.

JS API is about the same, with additional JS overhead.

There is no LiveAPI that I we can access from Java, neither from C.

- Is there a workaround to our issue here ?

- Do you plan to release an SDK to create full M4L externals, and thus allow developers to bend Ableton at light speed ?

- If not, will it be possible to use the LOM (with live.object/remote) at a decent speed in future releases ?

I tried by a lot of ways to control the live set at high priority without success.
I am in a project that requires to control Ableton's transport (tempo / position / play / pause) with a relatively high time accuracy. I need to set some live_set properties at a rates below 10 ms, in a timely accurate way.

live.object is:
- pretty slow (if I send more than 1 event per 20ms, it starts to queue events)
- async, but not a big issue
- tied to the undo history (can you imagine that with 50 actions per /sec )
- polluted by everything that happens in the UI thread

so-for-now-it-is-still-impossible-to-control-a-live-set-at-high-priority

It sounds like you'll need to use the live.remote~ object to do what you want, to the extent that you can. live.remote~ communicates with automatable parameters in the Live GUI, e.g. the values of DeviceParameters. It's not "strange" design, it's identical to the way MIDI mapping works in Live, and it was implemented to get around the limitations you cite, for values which make sense/are possible to change at audio rate.

The limitations of live.object (and the other live.api objects) are tied to limitations of the way in which the Live API (on the Live side) communicates with the application -- it is a GUI-thread API. Changing that would require changes on the Ableton side of things, and you might want to send them a feature request if you are unable to accomplish your objectives with the current toolset.

"It's not "strange" design, it's identical to the way MIDI mapping works in Live"

I understand that, but the fact is that some things are MIDI mappable under Ableton but still unreachable with live.remote~. I tried to use live.remote~ on the tempo, or nudge up/down, without success, while i am able to midi map these controls. This is because the live_set object in the API does not have DeviceParameters children which may allow to control Transport. The most relevant example of what i want to do is the msp/rewire hostcontrol~ object, which is unavailable in m4l.

Anyway, the thing that I want to achieve is almost working as a proof of concept with live.object at this time, because we managed to be smooth with the api calls. However, reaching all Transport live function at the speed rewire behave (Serato bridge is also a good example of efficient Transport control) would be very helpful to release a production state application.

I think this statement is way too defensive.

Cycling '74 has enhanced Ableton Live with a fantastic programming tool. But it seems you only have agreed on LiveAPI, integration of devices in the 169 bit Live strip and authorization of MFL.

Some innovative action would be welcome! Every interaction between Live and MFL seems to take 12 ms. The devision between Instruments, Midi Effects and Audio Effects really needs rethinking. More freedom for sending both MIDI and audio signals between all kinds of devices is needed.

Since the release of MFL, more than a year ago, we have only seen bugfixes and some small enhancements. Ableton explicitly stated that it was focussing on bugfixes and stability only.

I think it's time to think about improvements and enhanced functionallity again. Please have a conference with architects of both companies to discuss how to make Live and MFL work together even better. Perhaps a survey amongst users can help to get the right focus.

An announcement of innovative action of Ableton and Cycling '74 working together would be welcome.

"I think this statement is way too defensive."

Yes, and my post was a little bit aggressive too.

I totally agree with the fact that the current state of m4l is perfect for sound design, experimentations and live performances. The title of developers of the year 2009 for both teams was not stolen. But this is a little bit frustrating for the community that we cannot push real fresh stuff.

It would be very profitable for Ableton (Cycling did his best on this side) to release a real SDK, this way, a lot of fresh and innovative (and stable) stuff would appear on the community side that would enhance the Live experience. Think about video games and their mods community. e.g Half Life without modding would have never been at this level of gaming experience, thanks to their SDK and other tools released.

I'am off-topic now, and my concerns are more oriented toward Ableton, because you guys have done this SDK.

I totally agree with the fact that the current state of m4l is perfect for sound design, experimentations and live performances. The title of developers of the year 2009 for both teams was not stolen. But this is a little bit frustrating for the community that we cannot push real fresh stuff. 

Monsieur Xanadu - Your ardent plea is almost assuredly heard, after all, most of the main developers for Cycling74 peruse this forum, and those from Ableton's M4L project as well.

But do consider the lean economic times we are in, and the difficulty of making the large scale changes some of what you wish for would require

(to change the calling basis for the entire M4L from GUI level to signal processing level would be a huge rewrite: easily as large as the original work, AND would likely introduce as much instability as the original M4L port, if not *more*.)

Combine this with sales slowed by lagging economy, and demands for absolute performance stability, and I think any major rewrite such as you ask for will be a few quarters in coming, if not years. Sorry to be negative, just a reality check request from an old programmer, too aware of how too many rapid changes to any large code base (no matter how well designed) will always destabilize said code's functionality.

Just my tuppence, I hope i am wrong... but...

Monsieur Xanadu - Your ardent plea is almost assuredly heard, after all, most of the main developers for Cycling74 peruse this forum, and those from Ableton's M4L project as well.
But do consider the lean economic times we are in, and the difficulty of making the large scale changes some of what you wish for would require
(to change the calling basis for the entire M4L from GUI level to signal processing level would be a huge rewrite: easily as large as the original work, AND would likely introduce as much instability as the original M4L port, if not *more*.)
 Combine this with sales slowed by lagging economy, and demands for absolute performance stability, and I think any major rewrite such as you ask for will be a few quarters in coming, if not years. Sorry to be negative, just a reality check request from an old programmer, too aware of how too many rapid changes to any large code base (no matter how well designed) will always destabilize said code's functionality.
Just my tuppence, I hope i am wrong... but...
j2k aka cfb


Thus allowing fresh community developers making gears for everybody (and for free) is maybe a start of a solution.

I can't agree more mister Baker,
Thus allowing fresh community developers making gears for everybody (and for free) is maybe a start of a solution.


Of course I know it's hard to baldly go for improvement. I know economics are not good in general. I know ouw vendors are in a niche market because buying Ableton Live, MaxForLive, a fancy computer and audio equipment is quite expensive and not for big crowds.

What I mean is that I would like to see a statement (and then some action) that Ableton and Cycling '74 are working together to improve an a very good collaborative product.

But I see C'74 to urge users to ask Ableton for improvement. I see Ableton adding a lot of sonic content and a not-so-good received guitar amp model to their products. But no new features.

I have deep respect for both companies for offering us top of the bill music software. But I ask them to work together to improve.

So, for now, it is still impossible to control a live set at high priority ?