Cakewalk and Behringer X-Touch Problems.

I posted this in the hardware section but not getting any responses.
 
I had a previous post about this problem and thought it was resolved, but its not. 
If I power on my equipment rack, which includes the X-Touch (and its shown as working OK in the Device Manager) and then start Sonar Plat or the newer CbB the X-Touch is shown, correctly, as a control surface BUT apparently Sonar is not communicating with the X-Touch as the motorized faders are not working and the track indicators/switches do not work.  This appears to be a Sonar/CbB problem as I can start Studio One 3 or Cubase LE and the X-Touch is working OK with them.  
 
I can get Sonar/CbB to communicate with the X-Touch by deleting the X-Touch and adding a new control surface, Mackie Control.  After the delete/add the X-Touch works in Sonar/CbB.
 
The X-Touch and Sonar has worked properly for a long time.  The problem has been going on for a couple of months and I would suspect some Windows 10 update is causing the error in Sonar.  Something that has been heavily discussed here, a Windows update "breaking" Sonar.  CbB appears to be basically a rebadged Platinum version and most likely why Platinum and CbB both have the problem.

I have the latest Windows 10 Pro, Version 1709 Build 16299.371 and a dual boot Windows Insider V 1803 (a very minimal install on the Insider version - the OS, MS Office and Sonar Platinum/CbB).  It acts the same on both.

My X-Touch worked for a long time (I don't remember when I got it but at least 2 years ago). Then the problem started.  It could very well be a Windows update but Studio One 3 and Cubase LE do not have the problem.  Only Sonar/CbB has the problem.  

fireberd
Where is "Azslow"??

I am here. But I can not add much to what I have already written before:
* Sonar/CbB identify MIDI devices by names and tries to match these strings to what Windows return. The list is saved in %APPDATA%\Cakewalk\<Sonar version>\TTSSEQ.INI
When something is wrong here, the file should be deleted.
 
* Sonar 2017+ has introduced a bug in the matching system. As the result, even when "Control Surfaces" preferences show correct ports, in practice Sonar can use other (wrong) ports to communicate with the device.
That happens when TTSSEQ.INI information can not be matched with Windows information correctly, which in turn happens when:
1) in Windows Device manager, MIDI section, there are "bad" devices. The whole list can be seen only with "list not connected devices option". It is better to remove all orphan entries and in case active device is not "1", delete and reinstall it (f.e. reconnected to different port, physically or logically, leaving orphan entry as "1" and thinking it is not the first such device in the system)
2) there are devices which are not always connected when Sonar starts (sometimes that is ok, sometimes not). For troubleshooting, all MIDI devices mentioned in the Device Manager should be connected every time Sonar starts.
3) (any) device randomly "re-connects", f.e. with USB power management enabled, bad cables, bad USB hubs, etc. Can be observed keeping the Device Manager running, it visually "updates" the whole list where some changes are spotted. Alternatively can be seen in logs (more tricky to find).  USB power management should be switched off for all music devices, most of them glitch with this setting on.
 
* original Mackie Control plug-in requires 2 way communication present and working, it is stuck in "Connecting..." otherwise. My mod of this plug-in has "Disable handshake" option. That allows to check the Input from MCU (compatible) device is working, even in case the output is wrong. It also adds ProChannel EQ/Comp support and a workaround against Sonar crash in case MCU tries to control ProChannel Compressor (bug in Sonar).
 
So, brute-force way:
* delete TTSEQ.INI
* delete all MIDI devices in the Device Manager (including hidden!)
* switch off the computer
 
Then, for testing, every time boot the computer only AFTER all MIDI devices are powered and switch them off only after the computer is switched off. Do not put the computer into sleep. Check that in such case everything is always stable. If it is, try to add "features" one by one (f.e. sleep/wake, turning the rack on/off when computer is working, etc.), several times checking that things are still working. Till the reason is found...
 

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

When you delete TTSSEQ.INI, you delete MIDI configuration in Sonar. So you have to enable MIDI IO again and assign ports to surfaces. Note that you can change ports of MackieControl, I mean without remove/add procedure.
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?
* if yes, you reboot the computer, start Sonar: is X-Touch still working?
* if yes, you stop Sonar, switch off the Rack, switch on the Rack, start Sonar: is X-Touch still working?
* if yes, you stop Sonar, wait 1 hour, start Sonar: is X-Touch still working?
I mean we should identify what is triggering the bug in Sonar (no question that is a bug, but it is usually ineffective).
 
Different question: which MIDI mode you are using in Sonar? They have recently added second mode... 

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.
 

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.

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 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.
 

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.