How are things looking for you now?
Do you still have these problems with MIDI Remote?
Everything is ok for me.
Thanks for asking. No the icon V1-M/X settings are still not remembered by the midi remote. This is with 14.0.32 installed. Will give it a further test at some point and try slightly different config settings e.g. just using default Mackie device set up rather than using the custom script. The problem anyway with using the Mackie devices with the control surface and the 2 extenders is:
a) Mackie device does not support all of the features that the Icon V1-M/X is capable of.
b) The last time I checked it the remote settings are still not saved
So I still donāt think the problem is solved but thanks for asking
Best wishes.
1 Like
Just had this issue trying to use 3 different controllers with bjolucās scripts (X Touch One, P1 Nano, and an MCU). I was able to get one to reload as expected (the X Touch One) but when I tried adding the other two they wouldnāt load.
I read through the thread and tried a couple of solutions listed above. In my case, it turns out that the scripts themselves have some assumptions about MIDI port names for the controllers in/out mapping. In the case of the Behringer controller it worked the first time b/c the assumptions on the port names were correct in the script.
To get the other two controllers working, I simply had to search for the following line in the .js file (iCON P1 Nano as the example):
return detectionPortPair.expectInputNameStartsWith("iCON P1 Nano").expectOutputNameStartsWith("iCON P1 Nano");
The actual name of the port my P1 Nano uses is āiCON P1-Nano V1.22 Port 1ā - the missing dash in the default in the script was the culprit. To be safe I changed the line to include the entire port name:
return detectionPortPair.expectInputNameStartsWith("iCON P1-Nano V1.22 Port 1").expectOutputNameStartsWith("iCON P1-Nano V1.22 Port 1");
I did the same thing with the MCU and all 3 controllers load right up with no delay, and are basically auto-detected (you donāt need to set them up manually in Cubase).
Hope this helps!
4 Likes
Yet another example of why these scripts need dev support to be useful.
Why Steinberg and/or Icon hasnāt released an official script yet for Icon (and other MCU) conrollers continues to baffle me.
1 Like
Pretty useful here - and if just changing one line in the script to match your midi port names is all it takes, Iāll take it.
Agree that once you set up the controller and save it, no matter how you installed it, it should load. Thatās on Steinberg.
Iām glad you found a solution, and yes itās simple to implement once itās found, but searching through a massive script like this for a single missing character to get it working is just not an acceptable expectation for end users. Itās very clearly something Steinberg or Icon needs to actively maintain for users who donāt have time for this kind of thing.
While I have you - do you ever do any multi-fader movement with your control surfaces? I tried using the script for a while with an Icon P1-M but, among other issues, noted that Cubase freaked out if I tried to move more than one fader at once due to auto-select switching quickly between the faders I was moving.
Anyway Iāve decided that depending on these scripts is a non-starter for me until they get official support. Way too many bugs to sort through, both on the script and the midi remote API side.
This is not on the API side, itās on the script side. The creator decided to go with an auto-select approach obviously.
The thing is that IF the creator places a config file, easily read by the user, things can be different.
Example: In my script for the Keylab MK2, I have a config file, where I do have a line exactly for the auto-select:
This is not that hard for the user to alter, however, I must note here, that a creator can easily build a tiny app for such settings. No big deal really.
That being said, Iām with you on controllers getting official support. Though scripting can be an adventurous area even for starters, it should be left to the devs of the controller, at least for building a core script. Then, ordinary users, at least would know where to report issues, ask for new features. Enthusiasts could begin altering the scripts but it would be their own responsibility.
Nowadays I see manufacturers into scripting for the MR API. Some are doing an excellent job, while others compromise with minimal implementations. In the latter case, and since the structure of sysex/cc messages is exposed in the scripts, one can always move forward and build upon these ābasicā scripts. BUT when I say this, Iām not obviously referring to normal users, especially with no knowledge of the lang used, and without asking for help. In the case of a well written script, and if it gets shared, it wonāt be bad.
2 Likes
Iāve got an MCU (Behringer Wing Compact) set up with the 8 faders and can move them all at once. The Mixconsole slows down when doing this but they do register properly. If I move two or three at a time it looks smooth in the Mixconsole.
You can disable auto-select in the scripts - the author has a few switches at the top of each for configuring various things (like track visibility, etc).
Editing these user created scripts is part of the deal, but I do agree that the manufacturer provided scripts should work without having to edit things.
1 Like
With Icon V1-M it doesnāt work anyway on Mac Os, trying also to get real port names from System App but nothing, I suspect that this could due to using a USB Hub, but it is absolutely needed on my side, and on Cubase 12 it works flawlessly, even with this config.
Thanks a lot to all still waiting for a Steinberg definitive solution.
Cheers, Eriberto
1 Like
Hi m.c,
Iāve also considered what youāre saying, as there are now around 30 places in my script code that can be customized individually.
Writing an external application to adjust these settings would not be a problem. Iāve often developed similar things in the past. However, upon further consideration, the following must be taken into account: Windows and MAC must be supported in every system version; these apps must be provided with every script version; the app must be compatible with the system settings (Admin rights, cloud paths, etc.). In any case, support is also necessary if someone cannot find these apps, cannot start them for some reason, or has problems with access rights to the code.
With these individual script settings, I currently make sure that these adjustments are at the beginning of the code as far as possible and that simple constants with self-explanatory names are defined for them, which are provided with detailed, easy-to-understand inline code. So far, I had the impression that everyone was able to handle it well. Example:
// If the EQ LEDs, when the EQ is switched on, are to display the abs. EQ gain values,
// whereby this is represented by a gliding color from white to red,
// the code below should be: const gliding_LED_color_for_EQ_Gains = true
// Otherwise the EQ LEDs light up in full power red when the EQ Band is switched on.
//
const gliding_LED_color_for_EQ_Gains = true
In an additional app, there would of course only be a checkbox for this. In this respect, the idea of an additional app remains interesting, of course. 
1 Like
I agree with this. However, there are users who dislike (or afraid) to touch anything in a script. I understand them too.
If you find some time to check any of my scripts, for eg for the Keylab MK2, youāll see that I have separate files for different things. Hereās a screenshot of such files:
Initially I too had all the configuration at the top of my script. At some point, after sharing the script with some friends near me, and then after getting bored with answering āgo to line 43 and editā, I found it a tiny bit easier to have these separate files, so they could by themselves find the part they needed.
Iām using java for such apps, to be more precise B4J and then compile them for both systems separately. What Iām thinking is that I could create a generic config app, where you and other friends into advanced scripts, could place a json or xml for the parameters needed, and then this app would create such separate files which of course should be required in the script.
2 Likes
Thanks all for the recent discussion. Yup I found the relevant javascript lines in bjolucās script for V1-M some months ago. I tinkered around with them but with no solution as yet. What bugs me most is that all worked fine in Cubase/Nuendo 12 and does not in v.14.0.32. So the solution lies as much with Steinberg fixing the midi remote framework as users trying to find workarounds. We are in the summer lull now but come October/Nov we will presumably get into the annual paid release situation and the opportunity for point or hot fixes may recede into the background. I really hope also that bjoluc might come back from his academic commitments as his input is so crucial for the Icon hardware. Even Iconās newsletters mention him by name in connection with Cubase so I sure hope they are paying him something (although I doubt that also). Beats me also why Steinberg and Icon donāt talk to each other directly.
Best wishes and thanks to all here again for the discussion.
1 Like
Thanks for catching this @tuf! I just added the missing dash.
I have a documented config object with instructions at the top of my scripts where settings like this can be configured. It seemed too much of a hassle to me to maintain backwards compatibility with a separate, user-controlled config module, so I decided to keep it all in one file. This stuff is documented in my repo though 
@CKB Just read your post and couldnāt agree more ā Iāve thought about providing a config app multiple times too, but that seems like quite a ride to support/maintain 
Initially, I was hoping that the MR API would eventually see some basic script-defined config option support like some other DAWs, but I donāt think thatās going to happen anytime soon 
@m.c If you decide to fill that gap with a custom app, Iām interested to hear your experience with it! 
Hey, Iām back since spring ā thanks! ā but working full-time now and finding only little time to maintain the cubase-mcu-midiremote project. No payments involved; just my spare time (but thatās fine with me). Iām currently unable to reply to every forum comment (the amount of messages is overwhelming ā but I do typically read the notification mail to jump in if anything is burning) and Iām super grateful to everyone helping out here!
1 Like
Hi Bjoluc.
Great that you are back in circulation and hope your new f/t job is going well. Would be great if you could find a little time to advise on the continuing failure of Cubase/Nuendo ver 14.0.32 to save the state of the Icon V1 M/X. Your script was fine and dandy for me in Nuendo version 12 but has not saved with the nuendo file since ver 13.0.51 I think.
Best wishes
Hello,
I just found a simple operation that is working on my configurations:
- On my desktop PC, I first connected the P1-M controller alone with Cubase 14, so I installed the MCP protocol that was running fine, but without track colors, obviouslyā¦
- So I bought later the D4-T display and installed the bjoluc script that is running fine also, but with the disappearance problem we are discussing here
- I travelled this week with a lighter configuration, Cubase (14.0.32) on my laptop with P1-M / D4-T and an Akai MPK mini. I just installed the bjoluc script on the laptop, and surprise, after launching Cubase, the P1-M was popping up on the Midi Remote controllers window and it was fully operational (I donāt remember if I had to declare the ports or if they were already selected). From this moment, each time I launched Cubase and opened a project the controller was correctly initialized with the project track data, without any other operation.
- Coming back to my desktop this night, I tried to find which configuration could give the same result. This worked for me: in the studio configuration menu, āexternal controllers (herited)ā delete the Mackie protocol. In āMidiā section, Midi ports configuration, click on āreinitialiseā. After quitting Cubase and restarting, the behaviour is now the same on both machines, so Iām happy ! (some ghost instances may appear, but you can suppress them)
- If you really need the MCP, you will have to wait a software evolution, but if you donāt, you could try the same operation.
Have fun !
Just thought Iād add to this. I downloaded a bjoluc script for the behringer X-one. I use it with an ipad via rtpmidi using an app called Daw Control. It works great but I have to reload it every time I re start Cubase.
1 Like
And once again, two months have passed, butā¦
2 Likes
Yup, we are practically into the Cubase 15 launch prep season and Nothing further on this issue. Just an official moderator response acknowledging the problem would have been enough. The problem and the general short falls have been explained clearly enough both here and in other threads. The official Steinberg support desk were incidentally no help at all when I contacted them. That was months ago - iāve pretty much given up on solving this issue for now.
It was good to hear from Bjoluc but he is busy with his new job - and the responsibility for this stupid bug affecting icon V1-M/X is primarily with Steinberg. And the icon control surfaces are not the only products affected by this. The midiremote API is also crying out for further development - thatās all been said before as well.
Best wishes
Hi there.
Does anybody know another Script for the X-Touch that works ?
Greetings
Oliver
Letās see if the problem is fixed when Cubase 15 comes out.
1 Like