Man, I have no idea what you guys are talking about. Way over my pay scale 
 
I just followed the instructions for setup I found on YouTube
https://www.youtube.com/watch?v=l-8VO1vpc7U&list=RDl-8VO1vpc7U#t=506
 
I guess I'm going to leave well enough alone.
 
Fireberd, I really hope you can resolve your problem, because using the X-Touch is a really fine way
to arrive at a final mix.
 

The question is how stable it is, I mean:
* you delete TTSSEQ.INI, start Sonar, enable MIDI IO, assign to MackieControl, X-Touch works.
* you stop Sonar, start Sonar again: is X-Touch still working? - YES
* if yes, you reboot the computer, start Sonar: is X-Touch still working? YES
* if yes, you stop Sonar, switch off the Rack, switch on the Rack, start Sonar: is X-Touch still working? YES
* if yes, you stop Sonar, wait 1 hour, start Sonar: is X-Touch still working?  YES
 
"Yes" to all, now.  But it appeared to start working OK before and then went back to not working correctly.  
After I deleted the TTSEQ.INI, started Sonar and deleted/added Makie control it was working.  Rack was powered off for over 1 hour.  Powered it on and tried it and OK.   I powered off the rack, restarted Windows 10, powered on the rack, started Sonar and it was OK.  I'll have to wait until tomorrow and try it.
 

Next time, instead of deleting TTSSEQ.ini rename it. Having a "broken" TTSSEQ.ini to compare to a working file may help determine the cause of the problem. Also setting the file to read-only may  prevent the file from getting broken again.

Deleting the TTSSEQ really didn't make a difference.  After the deletion I started Sonar Plat and it had the X-Touch listed as a Control Surface but still wasn't working.  I had to delete it and add a new Mackie control before it would work.  That is no different than what I had to do before deleting the TTSSEQ.  After getting it working in Sonar Plat I closed it and opened CbB and had to do the exact same thing to get it working.
 
Its a "Sonar" problem (since Studio One 3 and Cubase LE do not have the problem). It had worked for a couple of years, thus suggesting if nothing has changed in how Sonar handles MIDI then something was changed in a Windows 10 update that only affected how Sonar handles these devices.  The Windows installed driver for the X-Touch is dated 9/28/17, V 10.0.16299.15

More info.  I booted into my Insider Preview version of Win 10 (dual boot with my production Win 10) which is V1803 Insider Preview 17134 (RS4 Release).  This is mostly what the Spring Creator's Upgrade is or will be (which has been delayed due to some "problems").
 
When I powered on the rack, I saw a notice on the screen that it "installed" the X-Touch.  Thinking back, this is the first time I tried it on the Insider Preview since the last OS upgrade.  I started CbB and the X-Touch worked properly.  I looked at the Device Manager driver for the X-Touch and found there is a later Windows installed driver, V 10.0.17134 (the version on "regular" Win 10 as noted is V 10.0.16299.15).  Maybe this is the key?? as I was having the same problems with the Sonar and the X-Touch before the last OS upgrade (??). 

I have the feeling the bug is Sonar can be triggered by the order of devices when it asks Windows for the list. When Windows re-install drivers, it can be the order is changed.
 
I wish CW/Bandlab just fix that.

I tried it this morning, PC was booted from power off over night.  Booted PC, powered on equipment rack (which includes the X-Touch) and then started CbB.  Same problem, I had to delete and add the X-Touch (Mackie Control) in the Control Surfaces section.
 
However, I then booted to the Insider version and its still working OK there.
 
So if its Windows causing the Sonar/CbB problem hopefully it will get fixed when the Spring Creator's upgrade (V1803) is finally issued.  The Insider version is 1803 and a later device driver.  
 
I'll report back after Microsoft finally issues the Win 10 V1803 upgrade.  For now I know how to "fix" it when using Sonar/CbB.
 

azslow3

pwalpwal
i'm surprised to hear they use string comparisons of device names

They are using the same in Project files. But that was also never working as soon as something is changed. They have tried to improve, in project files and in Sonar, with the result they have made it worse in Sonar and still nothing works for projects. I have hard time to believe they do not know what they are doing, but the result looks exactly like that is the case...

 
this week i had to explain to a developer why using string comparions on guids was a bad idea!
 

In projects that can be problematic, if the engine does not support re-appeared MIDI devices on the fly that is hard to add correctly. But simple MIDI device list is too simple to make any mistake. Till they have a bug in corresponding list enumeration (from other users observation, Sonar in fact "shift" devices in the list by one).

there does seem to be some confusion with 0- and 1-based arrays in there somewhere

According to an announcement on the tenforums.com, the delayed Win 10 Spring Creators upgrade will be available Monday, April 30.  Hopefully the new device driver version will fix this problem.