TDAbleton - getting device parameters as nicely as rack macros

Hey @Ivan had a question/topic for you ( and others getting deep on TDA).

I am trying to test out a setup where I control quite a few TD parameters ( 50 - 100 possibly) in a scene via Ableton. My preference would be to make simple M4L devices with basic parameter objects ( M4L knobs, sliders, etc) and just get those values via the DeviceParameters components. Of course I am now reminded of the very steppy nature of these incoming values and would much prefer the level of speed/precision you have setup for Rack macros incoming into TD. I’m totally willing to hack apart an existing setup to get into the more efficient OSC pipe you have for those values, but I’m not able to find it under the hood in max in the Rack components just yet, maybe some of it is embedded in the remote script?

I assume there is a barrier to just opening up endless flexibility for device parameters, but if I were making custom control devices ( as a point of reference the test setup i have has 7 of these devices with varying number of parameters, getting me up to ~75 values possibly) is there a way to funnel into that nicer macro Live > TD pipeline while still keeping things clean for use with the other TDA comps and devices?

Finally getting around to my goal of using Ableton as a beefier sequencer/animator, but macros are honestly just a bit too limiting in terms of being able to quickly add/remove devices that will control pre-built parts of the TD scene from a single track.

I wonder if I could make a few “stock” bpatcher widgets that can get their values into the pipeline and use those to construct these control devices and start using automation with them… any insight/pointers would be awesome!


Slight update now, i missed the tdConnection bpatcher in the rack OSC device, looking into this more now…

In general I think it would be better to build your own OSC senders specific to your project than to try to hack apart the TDA Rack Macro OSC devices. They are more complicated than you need and do some extra work for versatility.

Happy to share what I know about the details of sending OSC from Max if you have specific questions.

Ok cool, yeah seems that way. Another question, how are you setting your UDP IP and port settings in the various tdConnection bpatchers for output to TD? Does the remote script go in and do that for each one it can find somehow? Would be nice to get that info into a custom sender, I’m no Max expert so can’t seem to figure out how that IP address is getting filled when you change it in the tdPackage comp.

Your question goes into some deep TDAbleton magic. I’ll try to explain the basics, and of course ask more if you need further clarification or whatever.

The tdConnection bpatchers are included in most TDA Max devices. You can input messages into them and they send that to TD over UDP in an OSC format. They know where to send their messages using 5 max parameters: host0, host1, host2, host3, and port. The reason the ip address is divided up this way is because m4l doesn’t have string parameters that are accessible from outside.

The way you set a tdConnection to the current TD address is a special command to the MIDI Remote Script. Globally, you would use
op.TDAbleton.SendOSC('/tda/command', ['setDeviceNetworking', <lomExpression>])
although inside a TDAbleton Component’s extension it will look like this:
self.sendOSC('/tda/command', ['setDeviceNetworking', <lomExpression>])
The lomExpression in there is the Python live object model expression to get to the Live device in question (it will look something like SONG.tracks[0].devices[2]). If you have trouble figuring out what that expression is, the abletonValueListener component will help you figure it out if you navigate to the device with its parameters; just watch the Default LOM Expression readonly par.

If you want to mess with a tdConnection’s IP settings without the setDeviceNetworking command, you can access them directly as m4l parameters. They don’t have controls on the max devices in Live, but you can still access them via the abletonParameter component.

Hope that helps!