rack subdevices in the LOM: not yet implemented? or bug?

[ztutz]

I'm not able to access the device parameters for devices that are contained within racks.

I can see the rack and its parameters, but its subdevices neither show up in the devices collection for the track nor in the parameters collection for the rack.

Anybody know how to do this?

Thanks!

[ztutz]

Bumping for more info. Since posting the question and tinkering, I now see that Max subdevices in a rack show up if they possess a parameter to be automated and the right attribute values are set in the inspector. So I can both automate and modulate such parameters, using either automation lanes or clip envelopes.

I cannot, however, access these parameters programmatically. The subdevices neither show up in the Track devices collection, nor is there a property that contains them.

Since rack devices are exposed in multiple places in Live's public namespace, not being able to reach them from code seems like a bug? Anybody have more info on this?

[ST8]

This was the same in the python api. There was no way to access devices that were part of racks themselves, you could only get to parameters youd mapped to macros. I guess its unlikely that much has changed from the python api, the LOM looks pretty similar.

[ztutz]

Yeah, I've also used the Python API. I'd hoped that this limitation might be lifted.

I'm interested in building devices that "attach to" their neighboring devices, in order to modulate them, match them, mangle them, whatever.

To do this, I need to programmatically reach out within the device chain and locate the neighbors. Without having either the namespace exposed or else properties like device_chain or next_device/previous_device or such, I cannot modulate devices that are deep within racks. I suppose that I can "lock" my effect to a device like a deep hardware mapping, but that seems like a very clunky way to go (if it even works...) since it requires global configuration, rather than just plunking the device down next to its mate.

[mdk]

I'm interested in building devices that "attach to" their neighboring devices, in order to modulate them, match them, mangle them, whatever.

thats exactly what i'd like to do as well.

open up the racks please.

[fisk]

just adding my voice to the chorus in the hope that this may be sorted soon... i had the same idea as these two, hit a brick wall yesterday.

unlike most other DAWs, Live makes it difficult to select and load sounds, they have racks instead. this means that the only way to play a live set with a bunch of selectable sounds is to use racks.

the way Live.api is now, i have a choice of either only modulating 8 params per channel for the entire performance, or only having one sound/instrument loaded on that track for the entire performance. neither are particularly satisfying.

anyway i posted about this enough now...

[bencodec]

I'll add my vote here. It would be great to get some sub-rack communication.

[Michael Hatsis]

Id heart being able to get at devices in racks. To me, there must be something in the LOM to get T them. With my apc i can get at them,- so i would think that there must be some kind of hook to get inside racks.

[barnone]

Oh bummer, I need to get access to rack subdevices as well.

Well at least I won't spend more time trying to figure out how to get to them.

I can reorganize my set though to workaround it.

[amounra93]

+ 1.

(and I didn't realize you could get to nested devices with the APC.....looks like I'll be learning that control_surface in the meantime, since its the only thing in the API that can access devices inside racks....can someone confirm this?)

[Myralfur]

+ 1

[Jekblad]

not having access to devices inside racks ruins the Live workflow. Sad for me.

[pyrolator]

+1

would be great to have access to the rack subdevices......

[asha.dan]

+1 here too!