Limitations of M4L (e.g. rack access)

[skwosh]

Just a couple of things I can't live without. Feel free to add... [or to point me in the right direction if this has already been done].

1) Navigating from this_device within a rack. Trying to do anything with said live.object seems to fail. Which means I can't write device helpers (e.g. revamping Sampler) that can be grouped or used inside a drum rack.

2) Navigating by name or class_name instead of index. Crawling the immediate chain and matching by name is needlessly inefficient. I will get around to writing an index function in js, but nice if this was built in.

3) I don't have access to all parameters in Sampler, only the ones available to Macro/MIDI mapping. I want more!

#1 is huge, and I hope it's on the cards. I understand it's early days and Live is already ahead of the game in terms of customisability.

Cheers, Alex.

[pukunui]

Show us the patch for number 1.

Can't you just parse the path and then increment or decrement the device number?


-A

[amounra93]

I think that the clincher is that the device is inside a rack (am I right?). This is a limitation that is really killing me, too. If a device is inside a rack, the API gives a "get path:error calculating the path" complaint. Otherwise that would work fine....

[hoffman2k]

Same here. Waiting till somebody at Ableton or Cycling starts making work of these limitations.
Not being able to access racks would have been acceptable if this were Live 5. Meanwhile all our sets are based on Racks.
I tried working around it, but you can't deny its easier to have a chain for each instrument rather than a track for each instrument.

[Gregory Taylor]

The question of access to individual devices in something that Ableton has implemented - M4L supports what is currently implemented, and I presume that the current implementation is as it is for some specific reasons. Upon a little perusal of the manual and taking a careful look at the kinds of functionality racks provide beyond merely slapping devices together (stacking/splitting/layering/control grouping), I'll wager that the reason for the "lack" of support at present has a good deal to do with the complexity of the rack model - it strikes me as a considerable amount of possible complexity to support, and something I would approach with considerable care as a developer. While I'm as likely as the next user to think that the next improvement should be or should have been what *I* want next, I've found that it's not always the case that software engineering that which makes some arbitrary task appear easy to a user is not necessarily a simple task to implement or support. Perhaps my mileage varies from yours.

[hoffman2k]

The question of access to individual devices in something that Ableton has implemented - M4L supports what is currently implemented, and I presume that the current implementation is as it is for some specific reasons. Upon a little perusal of the manual and taking a careful look at the kinds of functionality racks provide beyond merely slapping devices together (stacking/splitting/layering/control grouping), I'll wager that the reason for the "lack" of support at present has a good deal to do with the complexity of the rack model - it strikes me as a considerable amount of possible complexity to support, and something I would approach with considerable care as a developer. While I'm as likely as the next user to think that the next improvement should be or should have been what *I* want next, I've found that it's not always the case that software engineering that which makes some arbitrary task appear easy to a user is not necessarily a simple task to implement or support. Perhaps my mileage varies from yours.

My mileage definitely includes a lot of not always understanding the developers point of view.
And I can see it might be difficult to find the device ID of something that is inside something with a device ID. But then I'm confused by things such as a hierarchical list of devices in the bottom right corner. It looks like its there but it isn't.

I also understand that M4L is added to Live without major changes to how Live works like the MIDI limitations and this current example. But it has to change at some point. All I can do is wait and occasionally state my hopes for change.
And the timing also isn't out of place because this isn't a pre 1.0 request anymore and for all we know Ableton is currently working hard on the guts of Live where this feature may be buried.

Its not like I'll throw a tantrum over this. M4L is the answer to many requests I made in the past.
My patience got rewarded. After these limitations are gone I really wont have much left to wish for.
But there will always be a wish I suppose. I can wait.

[pukunui]

Yeah, you're right, we need to deal with racks better in the API. I'll amend the tickets with this detail.

Thanks

-A

[skwosh]

Just to clarify - obviously I can live without this stuff. I just wanted to air my frustrations to see if anyone has worked around or if the developers are working on them. Thanks to pukunui for jumping in.

2) Navigating by name or class_name instead of index. Crawling the immediate chain and matching by name is needlessly inefficient. I will get around to writing an index function in js, but nice if this was built in.

I have to disagree on that point. It may give you more stuff to type in, but it will also make your patch a whole lot easier to read.

And quite frankly, its not that much extra.

The point is that lookup via name or class_name is more robust in the face of changing the order of devices, creating new devices etc than by chain index. It is also semantically clearer to say 'Sampler Reverse' than 'devices 3 parameters 1'.

3) I don't have access to all parameters in Sampler, only the ones available to Macro/MIDI mapping. I want more!

Could you elaborate a little on this one ?

According to the manual (which doesn't have to be fully correct ofcourse) the limitation isn't so much with regards to midi-mappable parameters but only the ones that can be automated. Of course I'm not sure if a parameter can always be midi mapped when it can be automated and vica versa.

That's kind of what I meant - more automatable parameters for Sampler. Not really a M4L issue as you say... I just assumed I would have access to everything.

[prebentious]

The question of access to individual devices in something that Ableton has implemented - M4L supports what is currently implemented

I believe that you can access and control devices in a rack from the next and previous device buttons on an APC40. Is that correct? If so, then that puts some doubt on your claim that M4L supports what is currently implemented. Not trying to cause a fight or anything, but maybe there's something that we're missing.

[amounra93]

Devices inside racks can be accessed through the "appointed_device" child of "live_set"....there is just no way to navigate (that I've discovered) to the device in the without MIDI selection or clicking on the device in Live. There is implementation for accessing the devices parameters....unfortunately there is just a hole in the implementation regarding how to select a particular device. (unless I'm missing something)

[pukunui]

This is why we have 2 modes for id.

- id follows path

and

- id follows object

Perhaps this will help you.

-A

[skwosh]

This is why we have 2 modes for id.
- id follows path
and
- id follows object

My understanding is that id is not saved, so even though id can follow the object, initially we still have to know it's position to navigate to it with live.path. Since position (instead of name) is hard-coded into the max patch, the patch will break if the position is changed. Correct me if I'm rong.

[hoffman2k]

This is why we have 2 modes for id.
- id follows path
and
- id follows object

My understanding is that id is not saved, so even though id can follow the object, initially we still have to know it's position to navigate to it with live.path. Since position (instead of name) is hard-coded into the max patch, the patch will break if the position is changed. Correct me if I'm rong.

That sounds about right. I start by assigning X to Y and end up with a path and ID. If you move things around, the path changes but the ID stays. So my patches keep track of the ID's. If I want to save these assignments, I have to take the ID's and convert them to paths. The paths are saved and the next time the Live set is loaded, those paths get converted to ID's to be used in the device again. The Clip Mapper device is a good example of that.

[broc]

If you move things around, the path changes but the ID stays.

Note however this (from the API Overview).

If the object is moved in Live, its id usually remains unchanged. There may be exceptions if the movement is implemented as a delete/create sequence, though. When an object is deleted and a new object is created at its place, it will get a new id.

[hoffman2k]

If you move things around, the path changes but the ID stays.

Note however this (from the API Overview).

If the object is moved in Live, its id usually remains unchanged. There may be exceptions if the movement is implemented as a delete/create sequence, though. When an object is deleted and a new object is created at its place, it will get a new id.

True. Also noteworthy are that the ID's are session specific, so (apart from paths) there's no way of ensuring ID's will be the same again on next load.