Is it possible for two or more scripts to conflict even if only one is loaded, as long as they are located in the folder C:\Users\YOUR_USERNAME\Documents\Steinberg\Cubase\MIDI?
Because of a bug with my WPF Sherlock2 window, we’re looking for all solutions and have removed the various JS files that were in the folder, including MC’s JS for the HTML demo inserts.
We also tried restoring from backups of the last few days of JavaScript and C#, deleting and recreating the LoopMIDI ports, but the symptoms persist.
I have normal access to my page buttons, PLEs, and macros, which all behave perfectly normally, as does my slider, which allows me to scroll through tracks. However, the Sherlock console reacts with a complete lag, not from Sherlock to Cubase, which works normally, but from Cubase to Sherlock, where there’s a 2-3 second delay. The fader buttons also flash with a scrolling effect, and the mute buttons light up randomly and/or flash.
Would reinstalling Cubase resolve this conflict? I have a backup of everything important anyway?
Perhaps I need to start again from the first JSON installation that m.c modified into JS.
Major slowdowns and port conflicts began to saturate the system as soon as the heavy page refresh structure was injected. In the folder history, the tipping point is precisely from the save: SHERLOCK2_BROWSER_PLUGINS_OK (and the subsequent test versions).
Why did it appear in this save?
It was in this version that two critical elements were introduced simultaneously:
The integration of the insert scanner: The explorerArbreComplet function (directly inspired by m.c’s mc_browser demo script) was implemented inside the mOnActivate handler of the production Sherlock script. On your giant orchestral template, this function started scanning thousands of branches with each page change.
The global loop across all pages (pages.forEach): To try and synchronize the buttons, the MixerBankZone callbacks (like mOnTitleChange and mOnColorChange) were configured to run on all 20 pages simultaneously. This is what multiplied the data volume by 20 with each single click on a track, causing the infamous 29,000-byte spike observed in loopMIDI.
Well, that’s what we assume.
What we might need to test:
The version just before, which was called SHERLOCK2_INSERTWINDOW_SIDE_OK (or the one that used the original m.c assignment files), worked smoothly because it simply managed the active page, without this background tree crawling.
Hello m.c.
For now, we’ve started from your original file js and assignments. We’ve regained responsiveness; the console faders work on the tracks selected in Cubase, but I still can’t select a fader in Sherlock. So, Cubase to Sherlock works, but Sherlock to Cubase doesn’t. All my pages work, all my buttons with Macros and PLEs work, the slider works, and the console’s Scrollviewer works, but the console isn’t updating to keep up with Cubase. I need to fix this first before re-introducing my Keyswitches, CCs, and Mics window.
On the C# side, we went back to the stable version.
Afterwards, it might be wiser to continue making some progress in the JavaScript by restoring the functions that were working before sending it to you once the steps are completed because to this day it no longer corresponds at all to the version before the bug of 07/06/2026.
I wonder why only the mutes and solos are causing bugs in Sherlock2. The buttons and console work perfectly; the colors, scroll viewer, and fader tracking are all there, but as soon as I touch a mute or solo button, it goes haywire, they flash, and the edit window opens.
I remember that when we created the first JSON (not JS) code with Gemini, these functions were linked to Keycommands and not to the transport buttons, which I believe are for physical buttons.
So far, we’ve recovered almost all the functions, but this bug makes the console unusable.
Claude and Gemini tell me about Feedback
I don’t really know what to think or what to do anymore.
Everything was working perfectly a week ago, and the problems started when the inserts were installed.
SHERLOCK2_BROWSER_PLUGINS_OK (and the subsequent test versions).