Except for the “legacy” midi implementation of Windows, there is also the WinRT. When we turn to this mode, you will notice that most (if not all) controllers have new/altered names.
This means, that in order to cover the WinRT implementation as well, we need to have another detection unit in the script, for these port names.
Same thing goes for Macs. So in order to cover the possible port names, we actually need three detection units.
Here’s for example how I handle this in one of my scripts, just to have an idea. And this is why I was asking for other users to send screenshots.
var midiInput = deviceDriver.mPorts.makeMidiInput("dawin")
var midiOutput = deviceDriver.mPorts.makeMidiOutput("dawout")
var detectWin=deviceDriver.makeDetectionUnit()
detectWin.detectPortPair(midiInput, midiOutput)
.expectInputNameContains('MIDIIN2')
.expectInputNameContains('Novation SL MkIII')
.expectOutputNameContains('MIDIOUT2')
.expectOutputNameContains('Novation SL MkIII')
// Windows RT
var detectWinRT=deviceDriver
.makeDetectionUnit()
detectWinRT
.detectPortPair(midiInput, midiOutput)
.expectInputNameContains('SL MkIII')
.expectInputNameContains('Port 2')
.expectOutputNameContains('SL MkIII')
.expectOutputNameContains('Port 2')
//MacOS
var detectMac=deviceDriver.makeDetectionUnit()
detectMac
.detectPortPair(midiInput, midiOutput)
.expectInputNameEquals("Novation SL MkIII SL MkIII InControl")
.expectOutputNameEquals("Novation SL MkIII SL MkIII InControl")
As we can see, we have three different combinations. Perhaps Faderport needs such combinations as well. So, one for “normal” windows drive, one for the RT driver and another one for a Mac.
This is a sad story as well. The thing is that especially on Windows, whenever I personally unplug/replug any type of USB device (not just MIDI Controller) I have many disconnections issues, irrelevant of Cubase. For example, I plugin a MIDI Controller, and I see my wireless mouse getting deactivated. All type of issues. That being said, I’m pretty sure that by properly re-quering the devices, devs at Steinberg can eventually sort the problem (if they haven’t done so already).
o.k., good idea. So maybe we could then suggest a corresponding script adjustment for Lluis after he has posted his screenshot here, as an interim solution until steinberg has the optimal solution…
Exactly! We need one user with a Mac, and another user with WinRT.
By the way, I did have users of my scripts with custom port names. In the end I came up with sharing a dedicated file just for the midi port names, so that I could be safe that their devices would be automatically detected.
Here’s an example of how my friend @Brian_Roland has his midi ports setup in this dedicated file for a script:
//Here we can define the custom ports assigned to Port 2 of the Keylab (DAW Port)
//var keyLabDawIn="MIDIIN2 (KeyLab mkII 61)" //DAW MIDI IN Port of the KeyLab
var keyLabDawIn="B" //DAW MIDI IN Port of the KeyLab
var keyLabDawOut="MIDIOUT2 (KeyLab mkII 61)" //DAW MIDI Out Port of the KeyLab
//When using the full version, here we can define the names of the virtual ports
//There are two pairs
//The first pair is for connecting to the generic remote and mackie
//while the second one is for custom inputs/outputs
var loopMIDIPortIn="mk" //First Pair MIDI IN Port
var loopMIDIPort1Out="mk1" //First Pair MIDI Out Port
var loopMIDIPort2In="mk2" //Second Pair MIDI IN Port
var loopMIDIPort3Out="mk3" //Second Pair MIDI OUT Port
module.exports = {
keyLabDawIn,keyLabDawOut,loopMIDIPortIn,loopMIDIPort1Out,loopMIDIPort2In,loopMIDIPort3Out
}
@CKB and @m.c
Your extended posts have allowed me to understand what was happening with my “Faderport”.
My mistake.
I have been talking about Faderport, but my configuration is a bit different.
I have an “ioStation 24c” which is a faderport with two input and two audio output channels.
This means that the midi ports are not called “Presonus FP2”, they are called “ioStation 24c MIDI In” and “ioStation 24c MIDI Out”.
Until now with version 13.0.41 this seemed irrelevant but with version 13.0.51 it seems essential.
I have changed the name of the midi ports and it seems to work correctly.
@LluisV You are the man - I have an iOStation as well and the exact same thing was happening with me. Your fix did the trick! ioStation activates every time now automatically like it used to. Thanks so much!
Thank You So Much WEM !! FP2 works now great with Windows 11 & Cubase 12 LE.
Please remember to change your FP2’s operation mode from Studio One → Cubase/Nuendo(MCU) mode. (See manual page 18).
@Jukka_Buddas
CKB has been working on the script for around two years and has developed it intensively.
You can find the latest version here, but there will be another new version soon, CKB said…
I don’t know why but sometimes the 10 lower buttons stop behaving correctly, they don’t light up as expected, it takes many reboot and reset for it to rework, right now for example even after reseting the unit I cannot make them work with the script.
The link button open the channel setting, but the master button doesn’t light up in orange like before and doesn’t make the main knob control the pregain
btw I must be really dumb but it’s hard to find the latest version of the script, lots of scrolling and I only find out of date version with no link aha
the master button even work on the shift page but not on the main page, very strange
edit: it’s working on an empty project tho
edit 2 : the only thing that fix the script it the to disable/enable of the script inside the midi remote on an empty project (must be empty, any previous project will make the script buggy again)
I tried to delete the temp files like mentionned above but it doesn’t fix the issue
In my experience this happens when opening up sessions from versions before Cubase 14. This has been the only cause for me but, that doesn’t rule out other causes.
To work around this, I’m completely stopped opening up any in Cubase 14 that was generated in a previous version, and instead, I’m creating a new session and importing the tracks. It’s not pretty, but it seems to handle the issue.
In my experience, once a session has caused the issue, the only fix has been a factory reset and update to new firmware… if I open a session in which the issue occurred, it will recur. It would require importing into a blank session.
If the issue occurs, and I don’t do a factory reset, and then open a formerly functional session and save that session while the FaderPort isn’t functioning properly, that session will retain the bug and it will break the script and require a factory reset if it gets opened. The only workaround I’ve found is to do the factory reset dance, and then import the tracks to a new blank session.
Is it normal for the Faderport buttons to send MIDI note on messages for monitored instruments?
I have never experienced this before and i’ve always had my instruments set to “all midi inputs”, but now the shift button is sending a note A#3 for instance. I’m almost certain i’ve used the faderport whilst having an instrument in monitor mode before and not had these notes triggering.
I was messing about with some midi settings today to try and disable some MPE functionality of my seaboard conflicting with quick controls. No idea if this is just coincidence but the faderport stopped being able to access QCs with the rotary encoder; at the same time I noticed the notes triggering. I reverted all settings, re-installed the script and restarted all software/hardware, QC control is working but i’m still getting notes playing when pressing various buttons like Write, Scroll, Channel, Next, Prev.
If the routing of the midi data coming from the Faderport leads to a midi track instead of an audio track, the Faderport there acts also like a keyboard. I think there can be various reasons for this, e.g. if the Faderport is selected as the input device for the midi track, which makes no sense. Maybe you check this out.