I am facing a severe latency issue (2-3 seconds delay) with my custom MIDI Remote script communicating with a WPF/C# application via loopMIDI.
When monitoring the ports in loopMIDI, a single track selection click in Cubase instantly pushes ~29,000 bytes of data to the input port (SHERLOCK-IN). The throughput goes back to 0 bytes/sec when idle, so there is no active MIDI feedback loop. It’s just a massive burst of data on every single click.
Context & Setup:
I am working with a massive orchestral template where many instrument tracks are deactivated by default to save system resources.
In my JS script, I use a MixerBankZone configured for 64 channels with .setFollowVisibility(true).
Inside the mOnTitleChange callback for this bank, the script transmits SysEx messages (for track names and VCA detection) for all available slots in the bank.
My question: Does a large MixerBankZone (64 channels) interacting with a project full of deactivated/hidden tracks cause Cubase to flood the MIDI Remote engine with massive chunks of redundant or empty string data upon track selection? How can I safely throttle or filter these updates within the JS script to prevent loopMIDI from choking?
The mOnTitle event gets triggered for every single channel of the mixer bank zone.
In order to avoid huge amount of data sent to the app, you will need to cache the channels’ names, and send them only when they really have changed.
Set Claude to inspect this code, where I do exactly this. Messages will be sent only upon a real tittle change.
// @ts-nocheck
var midiremote_api = require('midiremote_api_v1')
var deviceDriver = midiremote_api.makeDeviceDriver('Test', 'Mix Console 64', 'm.c')
var midiInput = deviceDriver.mPorts.makeMidiInput('anInput')
var midiOutput = deviceDriver.mPorts.makeMidiOutput('anOutput')
deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
.expectInputNameEquals('Bome MIDI Translator 1')
.expectOutputNameEquals('Bome MIDI Translator 1')
var surface=deviceDriver.mSurface
var mapping=deviceDriver.mMapping
var zoneSize=64
var page=mapping.makePage("Default")
var mixerBankZone=page.mHostAccess.mMixConsole.makeMixerBankZone("mixerBankZone")
mixerBankZone.excludeInputChannels().excludeOutputChannels()
var channels=[]
var cacheTitles={}
for(var i=0;i<zoneSize;i++){
channels.push(mixerBankZone.makeMixerBankChannel())
}
for(var i=0;i<zoneSize;i++){
channels[i].mOnTitleChange=function(activeDevice,activeMapping,title){
if(title!=cacheTitles[this.i]){
cacheTitles[this.i]=title
//send your sysex here
console.log("channel "+this.i+" new title: "+title)
}
}.bind({i})
}
I’m really frustrated when I see all the work accomplished in 5 weeks, first with Gemini, who, admittedly, made some mistakes but got the project off the ground, then with Claude, who seemed to have a perfect grasp of C# and JavaScript, given all the modifications he made and the immediate correction of his few errors. Then there was the implementation of inserts for the plugins; I think that’s where things started to go wrong.
In hindsight, I admit it’s largely my fault that I wanted a Sherlock2 with every possible option to find and even surpass Karol Obara’s original Sherlock, which had the drawback of being tied to the old generic remote control and had a few bugs since Cubase 12 or 13, I don’t quite remember.
We tried restoring from several previous C# and JS backups, but nothing worked.
Sherlock’s console is delayed by several seconds; some tracks flicker when the mute buttons are pressed—a real Christmas tree!
I don’t know anymore if I should try to repair it or start from scratch, or at least from the first two js and assignments you sent me, because we’ve been working on it for two days.
And I would really like to find a stable application, even if it has fewer features.
When I see where we were, it’s really frustrating.
Furthermore, we had downloaded your demo JS and HTML, and Claude made me remove them from the folder, telling me that it could disrupt our script, but since it’s not loaded, that’s not possible, right?
