X-Touch solo buttons not lighting up

[mkindred]

I was seeing an intermittent problem with solo buttons not lighting up on my X-Touch. I was finally able to reproduce it more reliably today.

It seems that the track/bus solo buttons/lights (and the Transport > Solo button/light) work correctly for a limited number of tracks (fewer than 20 is pretty reliable). Above 20-25 tracks, they begin misbehaving to the point that, with 50 tracks, the solo lights rarely work. The solo buttons do put the appropriate track into solo mode in Mixbus, but the lights on the X-touch just don't work. Often, clicking the "Channel ->" and "Channel <-" buttons on X-Touch (scrolling through the channels/tracks) seems to fix it temporarily.

This issue doesn't seem to affect mute, just solo.

I'm wondering if this is an error in the X-Touch or perhaps a limitation of the Mackie protocol.

Mixbus v9.2.172
Arch Linux

I did find an old archived post here that mentions solo buttons not working: https://forum.harrisonconsoles.com/thread-10177.html

[jeff_sloan]

I was seeing an intermittent problem with solo buttons not lighting up on my X-Touch. I was finally able to reproduce it more reliably today.

It seems that the track/bus solo buttons/lights (and the Transport > Solo button/light) work correctly for a limited number of tracks (fewer than 20 is pretty reliable). Above 20-25 tracks, they begin misbehaving to the point that, with 50 tracks, the solo lights rarely work. The solo buttons do put the appropriate track into solo mode in Mixbus, but the lights on the X-touch just don't work. Often, clicking the "Channel ->" and "Channel <-" buttons on X-Touch (scrolling through the channels/tracks) seems to fix it temporarily.

This issue doesn't seem to affect mute, just solo.

I'm wondering if this is an error in the X-Touch or perhaps a limitation of the Mackie protocol.

Mixbus v9.2.172
Arch Linux

I did find an old archived post here that mentions solo buttons not working: https://forum.harrisonconsoles.com/thread-10177.html

Are you using extenders?
Are you going through a usb hub?
May not have anything to do with it, but I also try to use usb ports on my computers that are not sharing other ports internally with other things, such as a UART or whatever they are called that is also hosting the mouse, keyboard, or any other thing.
I assume these data streams are one way, and not checked for receive, error checking, acknowledgement, etc.
So if the stream gets interrupted for a mouse, keyboard, sound device, whatever, then that data gets lost in the shuffle.
Therefore I get picky on which ports on the computer I use.

Try this:
When some of the lights are not lit up on the x-touch...
Go to mixer window, with the channel list showing.
Uncheck the first channel, and the entire screen of tracks will update, and all the data will be sent to the controller too, removing channel one and redrawing all the others across the controller.

Are the solo buttons lit now that should be?
channel back and forth, and even full banks of 8, don't make Mixbus resend all the data, as track names for me can get mixed up at times, and doing the above steps makes MB resend all the track info to the surface, cleaning it up.

I have been wondering for a while if there is a way to adjust the port com speed for communication to stuff like this, wondering if it was a bit slower, would less get "lost".

[mkindred]

I was seeing an intermittent problem with solo buttons not lighting up on my X-Touch. I was finally able to reproduce it more reliably today.

It seems that the track/bus solo buttons/lights (and the Transport > Solo button/light) work correctly for a limited number of tracks (fewer than 20 is pretty reliable). Above 20-25 tracks, they begin misbehaving to the point that, with 50 tracks, the solo lights rarely work. The solo buttons do put the appropriate track into solo mode in Mixbus, but the lights on the X-touch just don't work. Often, clicking the "Channel ->" and "Channel <-" buttons on X-Touch (scrolling through the channels/tracks) seems to fix it temporarily.

This issue doesn't seem to affect mute, just solo.

I'm wondering if this is an error in the X-Touch or perhaps a limitation of the Mackie protocol.

Mixbus v9.2.172
Arch Linux

I did find an old archived post here that mentions solo buttons not working: https://forum.harrisonconsoles.com/thread-10177.html

Are you using extenders?
Are you going through a usb hub?
May not have anything to do with it, but I also try to use usb ports on my computers that are not sharing other ports internally with other things, such as a UART or whatever they are called that is also hosting the mouse, keyboard, or any other thing.
I assume these data streams are one way, and not checked for receive, error checking, acknowledgement, etc.
So if the stream gets interrupted for a mouse, keyboard, sound device, whatever, then that data gets lost in the shuffle.
Therefore I get picky on which ports on the computer I use.

Try this:
When some of the lights are not lit up on the x-touch...
Go to mixer window, with the channel list showing.
Uncheck the first channel, and the entire screen of tracks will update, and all the data will be sent to the controller too, removing channel one and redrawing all the others across the controller.

Are the solo buttons lit now that should be?
channel back and forth, and even full banks of 8, don't make Mixbus resend all the data, as track names for me can get mixed up at times, and doing the above steps makes MB resend all the track info to the surface, cleaning it up.

I have been wondering for a while if there is a way to adjust the port com speed for communication to stuff like this, wondering if it was a bit slower, would less get "lost".

I'm not using an extender. I was going through a USB hub until just before I tested and posted here. I removed the hub to eliminate that as a possibility, but it seems to be about the same.

Yeah, I've also had some weirdness in sharing USB ports/hubs, especially between hard drives and keyboard/trackballs. But I've eliminated that as a possibility, to the extent I can  without looking at a schematic.

What you say about one-way com and interruptions make sense, especially since it's misbehaving more and more with more tracks to sync. It's interesting that 'Channel ->' and 'Channel <-' seems to reset everything. I wonder if that sends less data.

I will try your other suggestions soon.