Hi Martin, I can replicate this here, and I do recall we’ve seen this issue in the past and was reported.
Say we have 20 tracks. In the beginning everything is fine, tracks 1-10 are properly marked as remoted (white line).
Now, if we move to track 11, the following happens:
The knobs of the remote are properly mapped to tracks 11-20, however, the white line shows tracks 9-20 as remoted. This means that there is something like mixing up a default 8-tracks default zone, with the one we use.
Here are some screenshots.
We’ve selected the very first channel of our project. White line is fine.
Now, let’s select the eleventh track. We should see tracks 11-20 remoted. However, we see tracks 9-20.
And it can get even weirder. If we now select for example channel 10, we will see 16 (!) channels remoted:
I’m not sure if the above aligns perfectly with what @rothvin reported, but there’s an issue obviously.
Anyway, I’ve prepared a demo snippet to workaround this issue and show the channels that shouldn’t be remoted. Using Direct Access, we can query the remoted parameter value for each track in the mixConsole. IF this track is not part of the mixerBankZone (as correctly fetched by the API), we set its remoted parameter value to 0, and things are fixed 
Nevertheless, as said, it’s just a demo for perhaps helping identifying the issue.
Here’s the snippet:
// @ts-nocheck
var midiremote_api = require('midiremote_api_v1')
var deviceDriver = midiremote_api.makeDeviceDriver("Test","Ten Channels Bank","mc")
var midiInput = deviceDriver.mPorts.makeMidiInput("anInput")
var midiOutput = deviceDriver.mPorts.makeMidiOutput("anOutput")
var detectionUnit=deviceDriver.makeDetectionUnit()
detectionUnit.detectPortPair(midiInput,midiOutput)
.expectInputNameEquals("loopMIDI Port 2")
.expectOutputNameEquals("loopMIDI Port 3")
var surface=deviceDriver.mSurface
var knobs=[]
for(var i=0;i<10;i++){
var knob=surface.makeKnob(i,0,1,1)
knob.mSurfaceValue.mMidiBinding
.setInputPort(midiInput)
.bindToControlChange(0,i)
knobs.push(knob)
}
var mapping=deviceDriver.mMapping
var page=mapping.makePage("Default")
var mixerZone=page.mHostAccess.mMixConsole.makeMixerBankZone("zone10")
mixerZone.excludeInputChannels().excludeOutputChannels()
var daMixer=page.mHostAccess.makeDirectAccess(page.mHostAccess.mMixConsole)
var channels=[]
for(var i=0;i<10;i++){
var channel=mixerZone.makeMixerBankChannel()
channels.push(channel)
page.makeValueBinding(knobs[i].mSurfaceValue,channels[i].mValue.mVolume)
}
channels[0].mOnTitleChange=function(activeDevice,activeMapping,title){
var channelsIDs=[]
for(var i=0;i<10;i++){
channelsIDs.push(channels[i].getRuntimeID(activeMapping))
}
for(var i=0;i<daMixer.getNumberOfChildObjects(activeMapping,daMixer.getBaseObjectID(activeMapping));i++){
var childID=daMixer.getChildObjectID(activeMapping,daMixer.getBaseObjectID(activeMapping),i)
var remoted=daMixer.getParameterProcessValue(activeMapping,childID,4047)
if(remoted==1 && channelsIDs.indexOf(childID)==-1){
daMixer.setParameterProcessValue(activeMapping,childID,4047,0)
console.log("found should not be remoted "+i)
}
}
}
If we activate this script, and we for example navigate to track 11, we get the white line properly in the project (or mixConsole) window:
At the same we get at the console window:
These are basically tracks 9-10, which previously held the remoted property on and the script reset their remoted parameter value.
And here’s what it logs when we select track 10 (I mentioned earlier that in this case the white line covers 16 channels):
And we can see clearly again the issue, which is then handled by the script.
