check this workflow regarding MQTT client DAT

I’m learning how to use TouchDesigner, and have been playing around with getting sensor data from another host via the newly implemented MQTT Client DAT released in version 099.

The setup goes like this:

  • I have a few sensors, say channels 1-8, each publishing a stream of values to a topic.
  • Client DAT connects to server, attached callback script does the subscribing to each sensor channel topic
  • From the onMessage callback, we decide where the received data goes. Here’s where I’d like to know if my process is correct:

My current workflow is to grab an instance of a Table DAT, set the rows according to which channel it is. Now we have a table with multiple rows (say, 8), each corresponding to a channel. From here we can use a DAT To CHOP, and turn each row into a channel and send it off for further processing/use.

I could see an alternative where I directly grab an instance of a CHOP within the MQTT Client DAT callbacks and set the values there. It would be less visual objects in the network, but the tradeoff is then the mapping would occur via code compared to dynamically/visually.

Does the above make sense? It appears to work fine, but I wonder if this is the most elegant way to implement such a system, or are there other potential workflows for such a situation?

Any comments/suggestions welcome!

Some background info: I’m a PhD student in Music Technology working with this piece of hardware and trying to incorporate it with various platforms as part of an industrial collaboration, and TouchDesigner is one fitting application with a community that might find it useful.

youtube.com/watch?v=Q0QLILn … e=youtu.be

I have the same icubex slider used in your video, but I use the usbMicrodig into the PC via MIDIinCHOP. it’s super easy. I use dials for color grading, and the slider is geared for picking my LUTs.

In another network, I use 4 dials as Dolly, Zoom, Aperture, and Focal Length for funky movement in SOP 3D & Kinect Point Clouds.

I’ve expanded my midi setup to allow my MIDI keyboard, and various other midi controllers to come over the same USB port by using this setup. This way my icubex gear can act as extra dials for my Midi Piano.

  1. I cubex Sensors
  2. infusionsystems.com/catalog/prod … cts_id/204
  3. infusionsystems.com/catalog/prod … cts_id/305 this cable
  4. reverb.com/item/1248914-opcode-studio-64x
  5. ebay.ca/itm/2M-USB-to-MIDI-I … xyYYlRxAa0

would be interested in hearing about the hardware end of your setup.

I put together a custom Touchdesigner Mousepad with Icubex gear.


The hardware in this case moves the sensors onto a separate system (the Raspberry Pi) on the local network. Here we use the PiShield add-on board that basically provides an analog to digital interface (which the Pi lacks), and allows I-CubeX (or any other) analog sensors to be used with the Pi. I’m running the MQTT broker on the Pi itself, and publishing sensor data to it with another app running on the Pi (in this case, implemented in node-red, but it could be anything). TouchDesigner then connects to the broker and subscribes to “topics” of interest corresponding to various sensors that are available.

It does mean more separate components compared to using a local USB microDig and have all the sensors on the same computer, but the flip side is that it allows you to potentially scale up in interesting ways. (Or even subscribe to sensor feeds that are not physically present on your local network - of course, it depends on the usage scenario…).

In onMessage() I would take the data of the message and put it in your 8 or 9 row table:

op(‘table1’)[rownum,0] = data_from_message

That’s a lot simpler. Or you could put it in a channel.

op(‘constant1’).par.par.val1 = data_from_message

The python challenge would be to make val1, val2 … variable.

Re: “My current workflow is to grab an instance of a Table DAT, set the rows according to which channel it is. Now we have a table with multiple rows (say, 8), each corresponding to a channel. From here we can use a DAT To CHOP, and turn each row into a channel and send it off for further processing/use.”

I’m curious to see how simple this can be made and managed: sensors > I-Cubex > PiShield → MQTT Client on Pi, MQTT broker (anywhere) > TouchDesigner MQTT Client DAT.

Re: “The hardware in this case moves the sensors onto a separate system (the Raspberry Pi) on the local network. Here we use the PiShield add-on board that basically provides an analog to digital interface (which the Pi lacks), and allows I-CubeX (or any other) analog sensors to be used with the Pi. I’m running the MQTT broker on the Pi itself…”

Thanks Greg!

Apologies for the late reply as I’m travelling for a conference right now.

Since we’re on the raspberry pi, the simplest solution depends on a number of tradeoffs between ease of use and number of components/dependencies. For example, the way I hooked things up I have mosquitto installed from the default repos and launch the daemon (or have it boot on startup as a system service. some details here). Then, we need a sensor client driver to publish to the topic.

For a quick and dirty example I used node-red and created a simple flow that acquires channels of data from the A2D on the PiShield, and spit it out with a particular mqtt endpoint corresponding to the channel that we can listen to in TD. A more integrated solution might be to write a simple C/C++ app that does the same thing, which can then be executed as a program on startup. In this case, it would be two steps: 1.)install+configure mqtt on the RPi, and 2.)download+execute the sensor client app.

The current node-red way can be automated to run on startup of course, but requires another server application to be running alongside so is not the most elegant from a deployment perspective. (It is however quite convenient for rapid prototyping and experimentation however… imagine if you have a networked Raspberry Pi with some other sensors - maybe running as a remote sensor hub with some Arduinos or other devices, it would be easy to sketch up a flow to grab some custom sensor data and have it published via MQTT…

Before I left, I made a writeup here describing the above process.

Thanks! that makes sense. :slight_smile:

Hi Johnty ! Small world indeed :slight_smile:
I read the post but I don’t see where it talks about authentication to the broker or TLS ?
The broker I use is both TLS encrypted and password protected.

hi nat,

oops, i think in the other thread i meant to reply to the OP, and not specifically to your comment about authentication but it looks as if i did :slight_smile:. based on what i can see the authentication is not supported/exposed yet, so we’ll have to wait and see how it might be implemented :slight_smile: