Summary of the X-Touch

I own an X-Touch and want to make the best out of it. So there are some interesting topics in this forum.

What I want to do:

  • Use the track-color, convert it to the nearest color available on the scribble strips and send it to the X-Touch
  • Use the EQ-button to control a-eq. Select a track and press the EQ-button should show the parameters and let me control them with the encoders or with flip with the faders.
  • Control Plugins. Select a channel, press plugins, choose a plugin with the first encoder, while the other seven encoders show the parameters. Control more parameters by pressing the faderbank buttons. With flip send the values to the faders.
  • Using f1 etc. for mute groups. Holding for example f1 and select all channels which should be affected. When ready release the button and then it should function to mute all the selected channels.
  • Using f8 for tempo-tapping wthout opening the edit tempo function.

If all of this would work it would be such a boost for the workflow.

So has someone done some of this stuff? Otherwise I would try to integrate it myself with some lua and share it here (I have to learn it first). Let’s get the most out of the X-Touch with Ardour.

So here are some posts about these things:

X-Touch scribble strips? - #9 by Sahaathyva. So the scribble-strips are controllable with Mackie Control and there is a link to a lua-script. Has someone implemented it yet?

So @philsuess says the plugin-control was merged with Ardour 6. But my plugin-button does nothing? Is there something I have to do to get this working? Maybe a firmware update?

Also my flip-button does nothing.

So I would try to get everything to work (maybe some of this already works and my research was just bad), then make a step by step tutorial and post it here. Every help is appreciated :slight_smile:


Hey @comgang !

Welcome to this place!

I haven’t been here in soooo long. In fact I have been out of the hobby for equally as long. My guitar and all my stuff is in the basement and I don’t even have a running version of Ardour any more after switching distros, so I can’t tell you much about current affairs.

I can tell you that I implemented a full support for the xtouch and it got merged at the time I made that post you mention. The developers did make significant changes to my code afterward to make it fit better in their design.

I will lurk here and see what reactions come up on this topic. I would love if the xtouch got full support and I could also get back into the code base if there would be a need for it. Colours in the scribble scripts was something I thought would be cool, too…


thanks for your reply :slight_smile:
then I’m motivating you to start again :wink:

So, I’ve worked on the topic a bit and done that firmware update.

  • The send button work perfectly fine and also with the flip button which is amazing.
  • The EQ does nothing
  • But the plugin buttom at least shows me the plugins but I can’t change any parameters. Do I have to change settings for that, maybe set parameters for automation or something?
  • The track selection works, so filtering audio tracks, midi tracks, buses etc.
  • Transport is also fine.
  • rec, solo, mute etc. works
    so far so good.

So I wanted to know the controls that are sent to the X-Touch for writing on scribble strips, setting colors etc. and I made an image:

So I hope this helps some people, it’s helping me so far and I have done a bit of scripting:

ardour {
	["type"] = "EditorAction",
	name = "Send Color to X-Touch",
	license = "MIT",
	author = "Northern Light Audio",
	description = [[Send Color to X-Touch]]

function factory() return function()

	function getMackiePort()
		local a = Session:engine()
		local _, t = a:get_ports(ARDOUR.DataType("midi"), ARDOUR.PortList())
		for p in t[2]:iter() do
			local amp = p:to_asyncmidiport()
			if not amp:isnil() and amp:sends_output() and amp:name() == "mackie control out" then
				return amp
		return nil
	local asyncMidiPort = getMackiePort()
	local possibleColors = {0xFF0000FF, 0x00FF00FF, 0xFFFF00FF, 0x0000FFFF, 0xFF00FFFF, 0x00FFFFFF}
	local trackColors = {}
	local i = 0
	for r in Session:get_tracks():iter() do
		i = i + 1
		local color = r:presentation_info_ptr():color()
		local foundColor = false
		for j = 1, #possibleColors do
			print(color, possibleColors[j])
			if color == possibleColors[j] then
				trackColors[i] = j
				foundColor = true
		if not foundColor then
			trackColors[i] = 0x07
		if i == 8 then
	local message = {0xF0, 0x00, 0x00, 0x66, 0x14, 0x72, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF7}

	for j = 1, i do
		message[j+6] = trackColors[j]
	local parser = ARDOUR.RawMidiParser()
	for i = 1, #message do
		if parser:process_byte(message[i]) then
			asyncMidiPort:write(parser:midi_buffer(), parser:buffer_size(), 0)
			ARDOUR.LuaAPI.usleep(400 * parser:buffer_size())
end end

With this I can change the colors on my device but there are some problems:

  • The get_tracks() method doesn’t give me the right order of the tracks in some cases.
  • It just works for exact colors, not color ranges, but that’s just fine for me
  • the track color I get doesn’t change if I group tracks. So let’s say I create a drum-group with color blue, the method presentation_info_ptr():color() jus get’s me the track color from before the grouping. I couldn’t figure out the method to get the visible track color and not the underlaying color yet. Maybe someone knows?

And then, how do I call the script, when do I call it and how do I get the bank-position from my X-Touch?
Some thoughts:

  • My prefered method would be to run the script every time the color’s would change. So when adding or deleting, hiding, unhiding a track, when I press fader bank or channel buttons, when I change a color of a track or group some tracks. For that method I need to get the tracks that are shown by the X-Touch in the right order. Does anyone know how to do this?

I have some other ideas, but these are just stupid workarounds and I prefer getting it right.

I need to know how to get the current visible color of the track, not the underlaying color.
I need to know how to get the track id’s that are shown by the X-Touch in the right order.


This stuff should be added to the C++ Mackie Control Protocol support, not done in Lua.

1 Like

@paul I agree.

I compiled ardour today for the first time :smiley: but there are some issues. I get random letters on the scribble strips, some fader action is wrong etc… so not good for testing things.
Is someone testing something on the MCU protocol right now?
So I wanted to pull version 7.3, since I know everything works there, but I can’t figure out how to do that.
So first thing I tried was git checkout 7.3 but it’s saying “You are not currently on a branch” then.
Can someone tell me how to do that? Maybe in a private message if it shouldn’t be shared.

The “not currently on a branch” message is correct and not to be concerned about. It means your git repository is set to a tag, rather than a branch head (like “master”). We do not use branches for releases. However, unless you specifically want to build 7.3, there’s not much point doing this; using the current branch head is almost always the best choice, since you get our fixes (and new bugs).

Nothing is happening with the MCP support at this time that I am aware of.

1 Like

ok, then I will look into it. For the first steps these bugs shouldn’t matter.
I just need some time to understand the code. I will reply here if I have the first success :slight_smile:

the code you will likely be looking for will start in MackieControlProtocol::switch_banks() which should be called every time we change the strips (tracks/busses/vcas) being displayed

You’ll also want to add a new flag in DeviceInfo for “is xtouch” so that you change the colors if and only if the device is an xtouch, and then set that to true for the relevant device info files.

So, the first step is done.
The trackcolor will be converted to the nearest available color (so 8bit per color to 1bit per color) and then sent to the XTouch. If there is no track for a strip it will be off. The colors change if I hide a track, if I add a track etc.
some problems:

  • the colors don’t change at startup although the function get’s called. I have to press faderbank and then everything works as expected. I think there’s something wrong with the binding to the stripables. But I will take a closer look at that.
  • presentation_info is in stripable. And there’s only the trackcolor. If I group tracks together, the color in presentation_info stays the same.
  • If I change a track color there’s obviously no notifying. So If I change that I have to press channel or faderbank once.

So I think the color saved in presentation_info should be the same as the one that’s shown in the mixer and I would like to add a notification if the trackcolor changes. Some hints on that or places I should start looking?

Ardour does not have a concept of “group color applies to track color” i…e group color exists but it does not override the individual track color. Different UIs need to decide which color (if any) they will show, and where.

The notification about color changes will be a PropertyChange signal, with the argument containing (at least) Properties::color, so you need to attach a handler to that signal from the Stripable’s PresentationInfo

So I refactored the code now and I could commit it that way (just the track colors and the is_xtouch thing)
Should I commit this? And how should I commit it?

I pulled from github, not from

Just to say thanks, Alex/@comgang, for looking into this. I’m sure I, and philsuess higher up, won’t be the only ones keeping an eye on this thread and hoping that we might get coloured scribble strips at some point.

I was a bit gutted when I first learnt how limited the X Touch’s colour palette was, but then I came to the point of view that some colour, any colour, would be better than none and make navigating a lot of tracks a whole lot easier.

I find the X Touch really useful, so any improvement in its functionality with Ardour is a bonus. Thanks again for your efforts :+1:

Hey @Lost_Highway,
Thanks for your kind words. Yeah, would be pretty easy to add more colors, if you already have led’s in 3 colors build in. But for me it’s enough, I just group drums, bass, guitars, synths, vocals, so I need 5 or 6 colors. And you can get creative, so maybe do 8 tracks, blue and white alternating, then yellow and green then you already have a lot more options (and a lot more setup :D).

I hope I get everything done in that list. But it’s fun so far and I get more into the code, so the next lines of code should be a bit faster. But getting the plugins and EQ done will be more challenging.


The normal process is to submit a pull request. I’ll take a look, do a review, maybe make some suggestions, then merge it.

The request was merged right now. So trackcolors are in :slight_smile:

I’ve finally managed to update the firmware on my X-Touch (had been on 1.15!), thanks to the instructions here:

…then Googling to find out why it was bricked (RTFM: press channel 1 Select button on boot-up to select the protocol mode, though was already in Mackie, and more importantly change from network connection to MIDI).

And now, tubular… er, no, coloured scribble-strips! Hoorah :grin: Thank you so much.

The only problem I have now is that I can’t open any sessions in the nightly, they all segfault, so I had to create a new session to test the strips. But I can wait for the next stable release, knowing that this gift will be waiting :slightly_smiling_face:

ETA: the only thing is, after playing with setting the colours manually, black and white (#000000 and #FFFFFF, respectively) appear the same on the strips (white text on a black background). Is it supposed to do that?

It only has 7 colors. You can send it to the X-Touch with some midi tool. It’s described in the picture I posted above. So with #FFFFFF you assume that it has 8bit per color but it’s only one. So if you want to have it white you have to send a 7.

I think the confusion comes from the description of one as white (I see where that’s coming from, but it’s not what I was expecting), coupled with the fact that, prior to this, unused channels have never before been blank.

Apparently they’ve been white all this time, so I was expecting white to be the inverse of what it is (knockout text on an illuminated background, not white text on a black-but-kinda-illuminated background that it actually is) – seeing properly blank strips for the first time is quite stark.

Basically, I thought white was blank until I actually saw blank for the first time just now (and now I feel like Les Dawson, sorry, very English-of-a-certain-age reference! :rofl:).

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.