Sure. However I wouldn’t recommend this, simply because IF there is really something to be fixed it should be done by the vendor, so that all users will have the new better version.
Just had a look at their modules, they’re not obfuscated.
Just had a quick look, they don’t seem to have implemented something like the one I’ve done. BUT I will check again in the evening, maybe I missed something. Of course it would be much better if I could have this device, or a simulator, but I don’t.
Oh: you don’t have a LaunchKey 37 Mk4?
No, I have an SL MK3…
Anyway, I had a much closer look, indeed the issue that I had with my SL MK3 is not handled in the LauncKey script either, so by altering the script using my workaround, could make things better upon the initialisation process, i.e. whenever we load a project. But just that. It can’t be of any help when it comes to disconnections/reconnections. If interested, I can edit the original script so that you can give it a try and see if it helps.
I just had a thought: I’m still on Sonoma. Do you think a move to Sequoia may positively affect some/all of these issues?
I have not yet made the jump because I’m still a bit wary of making the jump, seeing as I’m not sure if my Steinberg CC121 will still work, amongst other things.
I don’t think this could be a problem really. The part of the “pads not properly lighting up upon initialisation” is solvable via changes in the script. The part of MIDI disconnections/reconnections is one that I for example haven’t experienced on Sonoma. But then, you never know…
I have no clue, does Steinberg mention something about not supporting Sequoia? Sorry, I don’t read much of such announcements, perhaps I should though.
So, more clues and clarifications from my side: Again, if I open up one of the Projects that have been previously “despoiled”, then how that presents itself is, every single one of the four functions that a user should normally have control over (i.e.: reading from Encoder #1, thru to Encoder #4, “Plug-in”, “Mixer”, “Sends”, and (my personal favorite) “Transport”) will not function properly.
On the LK screen what you’ll see will be the name of the first Channel of your Project, and if you turn any Encoder, you’ll see the number counter underneath the name and it will increment/decrement along with your turns, but there will be no proper changing of functions.
As a for instance: if I’ve chosen “Transport”, and then turned Encoder #1, then what normally happens is: that Encoder being assigned to the function “Scrub” means that the playhead will move as you turn the Encoder, and on the screen you will see the name of the function (“Scrub”), and underneath that name you’ll see the current position of the playhead (i.e.: 2.0.4, as a for instance.)
All that no longer occurs with any of the DAW-based functioning for the first 4 encoders.
I wanted to paint you a slightly clearer picture of what’s going on over here, thinking may that might help.
YES! I’ll definitely guinea pig on this one. I’m at my wit’s end with this issue.
And: might it help the situation generally if you had a LK Mini 37 Mk4 of your own with which to troubleshoot?
And, one more thing: I keep forgetting to add “Mini” to my description. My controller is LaunchKey Mini 37 Mk4.
It’s such a mouthfull-that’s why I’m often forgetting to include that.
No problem, from what I saw all these controllers share the same code 
Of course, most things that you describe if they come from the script side I would surely check and probably fix. I think I have a friend with a mini, I’ll ask if I can borrow it for a day or two.
Ok, I would soooo appreciate that!
And: did you see this post I left a little while ago? It started with this paragraph:
I was just wondering if those were helpful clues for you at all?
Sure. They all sound suspicious. By the way, you haven’t by any chance altered any knobs/buttons using the mapping assistant, have you?
Nope-none whatsoever. Their map remains pristine in my system.
I have made a map of my own, if that’s what you’re asking, but I made it completely on my own, without doing anything like duplicating their map or anything like that.
And: my map only covers 3 Pads and an encoder. Thus far I’ve not brought it out to cover the entire keyboard. No need, as of yet.
And: my map uses the LK’s MIDI port, whereas the factory DAW functions for the LK use the DAW ports.
So, from what I can see, MIDI Remote is treating them as two entirely different surfaces.
Of what? Do these symptoms speak to you of-or suggest to you-anything in particular?
No, but they give areas in the code to look for issues
Great-that was exactly my intent.
I’ll call my friend tomorrow afternoon, he’s djing right now, and I’ll see what I can do!
Cool! You’re definitely plugged in as a Music Maker.
I’ve seriously considered buying an SL Mk3, given how impressed I have been with the design (not implementation) of the LK Script, and yet, I realized that if I were to get it, the script I’d most likely be using is yours, since-correct me if I’m wrong-but that’s the only script out there available for the keyboard, yes? Novation hasn’t written a script for the SL MkIII yet, right?
I’ve owned a ReMote Sl 61 Mk1 since '09, and I still say it is one of-if not the-single best appointed controllers out there. It’s still a relevant piece of gear-extremely versatile and powerful.
The only reason why I’m no longer currently using it is: I bought an Arturia Keylab 61 Mk3 (I do still have a ReMote Zero sitting on my desk however, with MIDI Remote scripts I wrote connected to it.)
I was initially reasonably impressed with the Arturia, but having sampled Novation’s newest offerings I will say: Novation still does controllers the best. Their philosophy of what a controller should be best reflects what I look for in a controller. Arturia and Native Instruments both seem to build controllers almost as an afterthought, in pursuit of two goals: 1. to primarily control their own software, and 2. to sell more of their software. Applying philosophies in keeping with “how a truly useful and well-thought out controller should be” seems to kind of not have occurred to them, or have occurred only in scant circumstance.
Novation is not burdened by considerations of how to best fashion their controllers to service their VST products-because they have none. They seem to advance forward from an initial premise: what does the average music producer need/want MOST at his or her finger tips?"
So, IMO: Arturia’s implementation of basic functions like DAW control as a for instance, are overly clunky, inelegant and require too much button-pushing and menu diving. As I said before: these things come across-to me at least-almost as if they were afterthoughts.
Using a second “DAW” port for controller type functionality has become an increasingly common technique on modern hardware controllers. I’ve also seen that on keyboards by Native Instruments and Arturia.
Yes, and if you’re experimental like me, you can mess around with routing a hardware controller through another MIDI utility program (I currently use CoyoteMIDI), and split the MIDI from the hardware into several virtual MIDI ports (MIDI LoopBack), and fool the Cubase MIDI Remote into thinking there are multiple hardware controllers lurking inside my single hardware.