Remote Script for Behringer X-Touch

[RobrechtV]

Hey all, sorry for the unanswered questions. I'm afraid I'm not all that knowledgeable on Live remote scripts, or even coding in Python: I've been figuring it out as I went along, it's all pretty complicated, and unfortunately I haven't had a lot of time these past years.

I don't remember coming across a way to change the level LEDs metering to peak but I'll keep an eye out.

At the moment, I'm looking into colored scribble strips. I've been poking around and it turns out it is possible to change them from inside the Remote Control script (without using M4L), although what I've come up with is buggy at the moment and I don't know if I'll ever get it working well.

Bigger question is what to do (or try to do) with them. The Xtouch devices can only show six colors (red, yellow, green, blue, pink and teal), plus black (which renders the scribble strip text unreadable) and the default light blue/white. Ableton has a palette of 70 different hues, so it's not possible, not even in theory, to make the scribble strips reflect all possible track colors.

One way would be to try and assign scribble strip colors that are nearest to the track colors used, but even if I found a way to do that, it doesn't seem very practical to me. Ableton's palette is mostly pastel colors that have little in common with the pure colors used in the Xtouch. If your track colors are all soft hues with subtle differences, and you look at your Xtouches and just see rows of pure green and red, that doesn't help in identifying your tracks.

What I've been thinking about for my own workflow is this: I could pick six specific colors in the Live palette that correspond to those the Xtouch devices can show (so, again: bright red, yellow, green, blue, pink and teal), and program the script to recognize just those. If a track has one of those six specific colors, its scribble strip gets that same color. For all other tracks, the scribble script just keeps the default light blue/white color.

That way, you could use those six basic colors as a kind of highlights and assign them to key tracks around your project to make those easy to find on your Xtouch and Xtouch Extenders. Maybe I could include black too, to be used as a way to mark tracks as "don't touch" or something (since black makes the text unreadable).

But again, very early days and I don't know if I can even get that to work reliably. At the moment, the colors don't always update correctly and I don't even know where to begin to make them go away again when the channel strips are controlling, say, device parameters instead of tracks. But I'll keep you updated.

Edit – So this is where I am now. If your track is black, red, yellow, green, blue, pink or teal, its color is reflected on the scribble strip. If it is any other color, the scribble strip gets the default light blue/white. Additionally, if your project has fewer tracks than there are faders in your Xtouch + Extenders array, the remainder of the screens turn black – in other words: only existing tracks light up.

This basically works reliably now, with some issues. One: I can't switch the colors off yet if you switch to a different mode, like controlling parameters for a Live device (potentially annoying if some of the displays are black so you can't see them). And two: I'm getting crashes/freezes that I can't figure out yet. Try at your own risk (if you have downloaded a previous, working copy of the remote script, make sure to copy it to a backup folder first).

Edit 2 – The crashes/freezes may not be related to the script but to my USB setup. In any case, everything works fine if I only turn on the Xtouches after launching Live.

[j-cuc]

Hey, this is great! Thanks for the update. Highly appreciated.

I have my color solution running via M4L devices, and I’m happy with it. I’m currently mapping the colors to the closest possible match using jitter. However, a solution within the Control Script itself, like the one you’re working on, is much cleaner, of cause.
I will give it a go.

I think you should default to white instead of black so that alternative views are still possible. Don't you think?

Regarding the Peak vs. RMS… I found that
1. an armed MIDI track displays the levels correctly as PEAK whereas unarmed tracks display RMS.
2. if more than one track is armed, only the first selected one shoes levels at all.

Maybe this will help you find a setting in the script?

Cheers,
J.

[RobrechtV]

I think you should default to white instead of black so that alternative views are still possible. Don't you think?

Hm... that's a really good point. I do like the fact that only existing tracks light up (makes it easier to quickly see the state of a project) but if I don't find a way to switch all displays on specifically for alternative views, I'll change it to default to white as you suggested.

I have my color solution running via M4L devices, and I’m happy with it. I’m currently mapping the colors to the closest possible match using jitter.

That's interesting. How are you calculating the closest match among the Xtouch colors? Is it something I could implement in Python or a specific function in Jitter?

By the way, after some more testing I think the basic color functionality as I described above is in fact working and bug-free.

Notes:
- As stated, currently only specific colors are mirrored (red, yellow, green, blue, pink and teal, all found in the second row of Live's color picker, as well as black). Might change this if I find a convenient way to map all of Live's colors to the their closest match on the Xtouch.
- As stated, screens go black if there is no track associated with them. I'll change this if I don't find a way to light up all screens for alternative views.

One advantage of doing it in the Control Script is that the colors perfectly follow the tracks, even when folding or unfolding groups or banking up/down.

(If I find anything related to Peak vs. RMS, I'll let you know!)

[j-cuc]

That's interesting. How are you calculating the closest match among the Xtouch colors? Is it something I could implement in Python or a specific function in Jitter?

I am using the MuBu tool set from Ircam to "quantize" the colors. However, looking back… Maybe simply manually building a mapping-table of every Ableton Live color with it's most fitting Scribble-LCD color, should actually be straightforward - I can't remember why I didn't do just that.

(If I find anything related to Peak vs. RMS, I'll let you know!)

I appreciate that, thanks.

[RobrechtV]

I am using the MuBu tool set from Ircam to "quantize" the colors. However, looking back… Maybe simply manually building a mapping-table of every Ableton Live color with it's most fitting Scribble-LCD color, should actually be straightforward - I can't remember why I didn't do just that.

Yes, I was thinking about that as well – it's a finite list after all, just 0-69.

But! I wanted to try actual on-the-fly color matching first, and I managed to get it to work. That should make it more future-proof, should Ableton decide to change its color palette one day.

So now, the Remote Script takes the color of each track and compares it to all of the possible Xtouch colors.
- To calculate the distance to each Xtouch color, I used the formula (R-Rx)²+(G-Gx)²+(B-Bx)², where R, G and B are the values for the track color, and Rx, Gx and Bx are those for the Xtouch color.
- I assumed that the Xtouch colors are all combinations of pure colors, so red = (255,0,0), teal = (0,255,255) etc.
- The smallest distance determines the scribble strip color that is picked.
- I made an exception for black: a scribble strip is only turned black if you explicitly make that track black in Live. It was weird to get a black scribble strip for any dark color.
- All grayscales (where R == G == B) apart from black automatically get a white scribble strip.

For now, I also followed your suggestion and made white the default again for scribble strips without an existing track. If I manage to solve the alternative views thing, I'll make it black again.

To sum up: it works! Colored scribble strips!

For anyone who'd like to try, here's the link again.

[RobrechtV]

By the way, I found some code that looks like it may be responsible for the meters. It's in ChannelStrip.py.

Under "def on_update_display_timer(self):", from what I can tell, the difference between armed and unarmed tracks is that the meter shows input level for the former and output level for the latter. There are a couple of formulas for the variable "meter_byte" that are commented out (preceded by #). I suppose those are alternative calculations for the meter's behavior that someone experimented with.

I'm not going to mess with them for now but maybe you could start by activating those alternatives one by one and seeing how the meters behave?

Edit – On second thought, those calculations probably don't have anything to do with the slow meter response you're describing. I think it's due to a limitation in what Live makes available through its API. The description of the output_meter_level property used in the script is:

Hold peak value of output meters of audio and MIDI tracks, 0.0 to 1.0. For audio tracks, it is the maximum of the left and right channels. The hold time is 1 second.

There are also separate output_meter_left and output_meter_right properties that offer the "smoothed momentary peak value" of the left and right channel meters. However, their description notes that they " add a significant load to Live GUI resource usage". I gave output_meter_left a try and the meters did indeed behave much snappier, but only a few of my tracks actually showed meters, so it doesn't seem to be working well. And, of course, you'd only see a meter for one side of each stereo channel.

You can try this for yourself by opening Xtouch/ChannelStrip.py, looking for "output_meter_level" and replacing it with "output_meter_left".

[RobrechtV]

For now, I also followed your suggestion and made white the default again for scribble strips without an existing track. If I manage to solve the alternative views thing, I'll make it black again.

For anyone who'd like to try, here's the link again.

Alright, I solved the alternative views thing! Now I can switch the displays on specifically for some alternative views, so I can turn off the unused screens again in default mode, which is much cleaner. Updated the files behind the link above.

I made it so the screens all turn teal for Sends view and yellow for Plug-in (device control) mode, so not only can you read them all, but you're also reminded of the mode you're in.

For Track (IO) and the default Pan mode, you only need to see the displays where an actual track exists, so in those modes all non-existing tracks go black.

[j-cuc]

@RobrechtV, your efforts are truly appreciated. It’s hard to overstate what a game-changer track colors are!

It seems I’ll be retiring my M4L solution in favor of your script—bravo!

I had started working on a way to display the currently playing clip name in the second row of each track. While doing so, I imagined a mode where each X-Touch track’s Rec/Solo/Mute buttons could transform into “Launch,” “Up,” and “Down” buttons for the session grid of that track. This feature would take performing in session view with X-Touch to a whole new level. Perhaps something for you to consider as well, along with the RMS vs. Peak stuff.

Once again, I can’t thank you enough for your incredible work.

Cheers,
J.

[RobrechtV]

That's an interesting idea. It feels like it's way beyond my capabilities and knowledge of how the script works at the moment but I'll keep it in mind as I poke around in its files.

[j-cuc]

Short note: I noticed that the level meters behave even more erratically for me when more than one track is armed.

[RobrechtV]

There are also separate output_meter_left and output_meter_right properties that offer the "smoothed momentary peak value" of the left and right channel meters. However, their description notes that they "add a significant load to Live GUI resource usage". I gave output_meter_left a try and the meters did indeed behave much snappier, but only a few of my tracks actually showed meters, so it doesn't seem to be working well. And, of course, you'd only see a meter for one side of each stereo channel.

OK, I gave this another try.

- Instead of just taking one of those output_meter_left and output_meter_right properties, I now take the maximum of both – that way you still get an indication of overall volume instead of just one stereo side.
- Using that property instead of Live's output_meter_level, the meters are a lot snappier, like I noticed before.
- I'm not seeing any change in resources used by Live.
- I found out why not all tracks showed meters before: one of my tracks was a MIDI track that didn't have an audio output (it was routed to another channel). This caused an error when the script tried to read its output_meter_left/right property, breaking the meter for all subsequent tracks. I now changed it so the script first checks if the track can actually output audio, and that solved it.

Long story short: new version behind the link has snappier meters.

About having more than one track armed: what I'm seeing is in that case, only the selected track has an active meter. There's no reason for this (that I can see) in the script's code, so it's probably a limitation in Live.

[j-cuc]

You are absolutely awesome! Thanks.

[Kik07L]

that's just perfect man, TYSM !!!! do you mind if i post your code on github with a readme link to here and ur name ?

[RobrechtV]

do you mind if i post your code on github with a readme link to here and ur name ?

I've been thinking about that. I've never worked with Github myself (not a "real" coder, just a curious tinkerer) but it would be cool if others could benefit from and add to the project. So sure!

[RobrechtV]

By the way, I've added a fifth page to Track mode. The first four pages already existed in the Mackie Control script: they allow you to set each track's input and output type and channel using the rotary knobs. Press the Track button one more time and you enter the new color mode: each track's scribble strip displays the name of the current color and you can use the rotary knob to change it.