accessing devices inside a rack

[mdk]

is this possible?

If I use the SelectDevice abstraction then I can only see the rack, not the device inside.

e.g. I setup a MFL device to modulate some operator parameters but then if i put it in a rack i'll have to map the operator params to the rack macros and then modulate those from the MFL device, which of course limits me to just 8 parameters.

(tbh I remember this being a limitation when using the python API so im assuming its still the same situation)

[Poster]

yeah.. I found that quite limiting..

though there's a little hack I found.. not a proper solution but it shows it can maybe work afterall..

if you first route the LFO to a device parameter and then group the LFO and the device to a rack the signal path stays intact..
you can now even drag the LFO out of the rack and it'll still work..
as long as you then dont refresh device list you're all fine..

[mdk]

nice. i made the mistake of hitting refresh when racking / unracking. it'll do as a workaround, and i guess it shows that the actual id's persist so there might be a way to do it 'normally'

[3dot...]

I really hope there's gonna be a simpler solution to this issue...
racks are part of the hierarchy..

[fisk]

just discovered this myself. in some instances it appears its easier to interface between Max and Live as separate apps..

[ztutz]

Here is related thread from a week back on the rack issue:

http://forum.ableton.com/viewtopic.php? ... 60&start=0

IDs do seem to remain unchanged up to set save time. But every time you load the set anew, you'll have to do the same tricks??

I agree that this is a pretty big omission from the programmer's perspective. Your device cannot dependably reach out to manipulate the rest of its device chain, leaving it on par with a VST. Well, that's not quite fair, but you get my gist.

@fisk: it would be totally interesting to do a careful quantitative comparison of M4L versus Max+Live integration.

[fisk]

It is a serious limitation if a so-called midi plugin cannot even modulate parameters of successive midi devices.

[hoffman2k]

Here is related thread from a week back on the rack issue:

http://forum.ableton.com/viewtopic.php? ... 60&start=0

IDs do seem to remain unchanged up to set save time. But every time you load the set anew, you'll have to do the same tricks??

I agree that this is a pretty big omission from the programmer's perspective. Your device cannot dependably reach out to manipulate the rest of its device chain, leaving it on par with a VST. Well, that's not quite fair, but you get my gist.

@fisk: it would be totally interesting to do a careful quantitative comparison of M4L versus Max+Live integration.

Don't forget M4L brings support for the API that already exists.
It is an omission, but apart from a few little changes the API is still very much the same as in Live 7 or even Live 6.
Keep in mind that anybody with a decent grasp of python can go ahead and create their own API hook. But even they are dependent on the features that Ableton allows us to access.

I agree you should be able to control any device anywhere. But there hasn't been a controller yet that supported such thing. So chances that the API supports it are very slim. M4L is literally the first step towards an official API, which means we can make requests now. So far there hasn't appeared a single user request in the API. They're still working on exposing what is already there.

It is a serious limitation if a so-called midi plugin cannot even modulate parameters of successive midi devices.

You can modulate anything that isn't in a rack. If you need layered sounds, skip using racks and use group tracks instead.
If you do want to use racks, you'll have to work around it by building a satellite device to place in your rack. So it can send data from within the rack to anywhere else.

[fisk]

i'm using racks as a means of selecting sounds, this is impossible any other way in Live, afaik.

am i expected to perform for an hour and only modulate 8 params per track? or only have one sound loaded the entire time?

its ludicrous...

[hoffman2k]

i'm using racks as a means of selecting sounds, this is impossible any other way in Live, afaik.

am i expected to perform for an hour and only modulate 8 params per track? or only have one sound loaded the entire time?

its ludicrous...

Yeah, if you use the chain selector as a means to control your set, it will indeed be hard to control multiple devices within that rack.

There are a few solutions, I'm not sure if you care for workarounds though.
The first one that comes to mind actually saves you some CPU power.
If you build a Track Selector to replace the chain selector and use tracks instead of racks, the CPU usage will be spread out over multiple cores. As opposed to all the devices within a rack. Depending on the devices you use, this may only be a marginal increase of CPU headroom. But still, not all workarounds are as nasty as the word suggests. Track selection wasn't possible before M4L.

2 ways I see to implement it of the top of my head. Either rig something up with the API that controls the monitor state of a track. Or build a device that gates incoming signals to gated tracks.

[fisk]

thanks, nice solution, altho i have like 20 chains in each rack so thats like 80 tracks, can Live handle 80 plugins loaded simultaneously? i thought the idea of racks was to dynamically allocate cpu, not sure how i would save cpu doing this. i will give it a go but its gonna be incredibly long winded compared to selecting a parameter with a menu.

[fisk]

alternatively maybe Ableton can look at allowing me to load new presets into currently loaded/running plugins/instruments without having to use racks and chains. that way at least the many instances i have to have of the same instrument can be reduced. i only use chains cos it was the only way to load a new sound into an existing track that i could find. all i originally wanted to do was load a new preset into the instrument.
i guess one limitation leads to another..

[fisk]

just testing this
a rack containing 15 different plugins uses about 25% more cpu than the same plugins loaded into 15 different tracks.
mental...

wow i have a long week ahead now, lol

[fisk]

christ this is doing my head in already

all the params are currently mapped to midi controllers.. is there no way there can be an equivalent mapping performed internally? like an imaginary midi port or something. this would make porting midi sequencing stuff a breeze..

it seems so crazy that midi messages can be parsed and dealt with in time but the same message can't be sent from one part of the software to another. it's not like it's a lot of data

[hoffman2k]

So you see, there are plenty of problems to solve already without running out of API features.
I'm on the same boat, I want to control a lot of things and want to keep the CPU usage low.
My problem isn't so much with accessing the depths of a rack, its working out how to control the depth of a whole set. From a limited amount of controls.

Ableton could make this a lot easier on us, but by now I'm pretty sure "program changes" are somewhere high on the to do list. M4L has the advantage that we can make more elaborate workarounds than we already have to do using Live normally.
We work with what we got.. There are features I want to see in Live. Things I've been asking for for ages. Some of those things can actually be done now.

My point is, I'm already too distracted with what is already possible at this very moment to come up with proper requests for Live that I haven't already requested before.

Anyway, back to the drawing board