Feature whishlist for the LiveAPI

[Crubier]

Hi all,
Many of us definitely need some improvements in the LiveAPI, because some inconsistencies or bugs really prevents many of us from completing some devices.
This topic is here to gather all demands for the next generation of the LiveAPI, because we really need it.
Please try to explain the need precisely, giving examples if necessary, and the concerned part of the Live Object Model.
If anybody knows how to contact the cyclings or abes that are developing Max for live, that would be great.

Ok, Let's get it started :

1)
Part of the LOM
loop_start, loop_end and looping properties of the Clip Object
The need
Have access to clip start/end points when clip is looping, and loop start/end points when clip is not looping.
The problem
For the moment, when the clip is looping, one can't access the clip start point, because the loop needs to be disabled to get it.
In the LOM doctumentation, we can see this description for the loop_start property, and this is the problem :
For looped clips: loop start.
For unlooped clips: clip start
Example
The problem is explained in this thread :
http://forum.ableton.com/viewtopic.php?f=35&t=146610

[Gregory Taylor]

If whishes were hhorses, bheggars would rhide!

[olivierseb]

If whishes were hhorses, bheggars would rhide!

very funny Ghregory

btw : I think it is a very good initiative to open such a whishlist, as long as issues are well documented and demands concise.

+1

Olivier

[timeline85]

Please give us complete access to MIDI ports so we can access all of the raw MIDI data within! Oh to be able to control multiple MIDI channels from a single patch, or to delve into SysEx or PolyAT.

[barstu]

i whish i could acces to devices in a rack

[pucklermuskau]

"the move_playing_position call should allow for absolute positioning in the clip, rather than the relative behaviour it has now. As it stands now, it is not possible to consistently and repeatedu; jump to a specific place in the clip. I want to be able to map a row of 16 buttons to 16 divisions of the playing loop brace. Right now, i have to observe the playing position of the clip, calculate the difference between the playing position and the desired division, and send a relative value message via move_playing_position. This produces inconsistent results, while it would be a more straightforward exercise to simply say 'move to beat 5 of the playing clip'. Ideally, behaviour similar to the chucker max object would be ideal, but acting on the loop brace area of the playing clip, rather than on a recorded buffer."

[tchan]

+1 to enable absolute positioning of the move_playing_position command. we need a rock solid sync between live + m4l to extend all the awesome sample cutting devices that have already been developed!

[amounra93]

+1 for rack access. That's a biggee.

API support for getting the "parameter value name data" from the _framework libraries in a way that it can be used. (e.g. -3.5 dB instead of 93.0 or whatever).

(It is currently already available via the API, but it isn't parseable. All names show up as a single array, but since each item has a variable length, there is no way to find out which value is for which parameter)

Multichannel MIDI routing is essential, but we are working on a workaround for this, at least. Or a send/receive object that is capable of performing a similar function and is timing accurate (and doesn't break when flooded with too much data).

Dependable audio sidechaining, for the same reasons.