As shown, the cc1 data does get to the vst instrument, but cubase just doesn’t want to record this cc1 data in the midi clip.
Strangely enough if I go to Midi - CC Automation Setup - and select the option to record midi cc as automation track rather than in the midi clip, cubase properly records the cc1 (but i really hate having the cc as automation track).
There is nothing filtered out in Preferences - Midi Filter, the midi port through which the cc data gets put in is activated in “All Midi” in the Midi Port Setup.
What other settings could be setup incorrectly to cause this error?
(Info on my setup: Cubase 13.0.20, MacBook M1, the daw controller that is used to input the cc1: Icon Platform M+, using the Midi Remote API script from this thread Icon Platform M+ MIDI Remote - should work with any MCU based controller , but I don’t think there is anything wrong with the script, because the cc1 data does get delivered to the instrument track correctly and that is all the script is supposed to do (in this use case). And nobody else over there seems to have the same probleme as I do)
I see that in your first video W button is not enabled in Inspector panel, so I guess that’s why it’s not recording the automation. Still confusing, as it’s enabled in the Kontakt window itself…
Shot in the dark: If you switch off the W button, does that change anything? MIDI CC gets recorded as normal midi data independent off automation write on/off.
My other thought would be that CC#1 is occupied by MIDI Remote.
no, switching off W button in inspector as well as Kontakt also doesn’t change anything.
I don’t think that the MIDI remote can occupy the CC1 in this case, because the midi Remote script is actually generating the CC1 data in the first place in the current setup. I would be very surprised if the MIDI remote can occupy it’s own ouput.
well yes, I can change record destination to automation track, and things will work that way. But I really hate not having my cc data in the midi clips, I don’t really want to work that way.
The daw controller (Icon Platform M+), sends data using macki protocol (for this fader it’s sending pitchbend data) to cubase. This data enters cubase through the port Platform M+ V2.19 IN.
Yes on a first guess I would also think, that a user created Remote API script is the probleme, but if the script wasn’t working, then why does the correct CC1 data even reach the instrument? The correct CC1 data gets put into the instrument track, it’s displayed correctly in the midi monitor and the vst instrument behaves correctly according to the incoming modwheel information, just cubase doesn’t want to record this data in the midi clip.
And as far as I can tell I’m the only one who has this probleme with this script, so I suspect that it’s an issue somewhere in my cubase settings. But I don’t really know anymore which settings to look at at this point
@Johnny_Moneto I am the midi remote script author and the relevant code snippet is:
function makeMidiCCBinding(page: MR_FactoryMappingPage, displayName: string, cc: number, fader: number) {
// ? I have no idea what page.mCustom.makeHostValueVariable actually does- all I know is I can make a value binding this way. I can't seem to be able to look it up
// ? or access it all once made.
page.makeValueBinding(device.channelControls[fader].fader.mSurfaceValue, page.mCustom.makeHostValueVariable(displayName)).setValueTakeOverModeJump()
.mOnValueChange = (activeDevice: MR_ActiveDevice, mapping: any, value: number, value2: any) => {
var ccValue = Math.ceil(value * 127)
var pitchBendValue = Math.ceil(value * 16383)
var val1 = pitchBendValue % 128
var val2 = Math.floor(pitchBendValue / 128)
// this is the value going back to the icon Fader
device.channelControls[fader].fader.mSurfaceValue.setProcessValue(activeDevice, value);
// this is the value going back to Cubendo - only send if touched
if (device.channelControls[fader].fader.mTouchedValue.getProcessValue(activeDevice) === 1) {
device.ccPortPair.output.sendMidi(activeDevice, [0xB0, cc, ccValue])
}
// Update display
device.lcdManager.setChannelText(activeDevice, 1, fader, displayName);
device.lcdManager.setChannelText(activeDevice, 0, fader, ccValue.toString());
}
}
This works correctly on my Windows 11, Cubase 13, Kontakt 5,6,7, Halion 6,7 etc instruments with Loop MIDI providing an unfiltered virtual midi port which is bound in MIDI remote to ccPortPair.
Update: I found a work arround that is good enough for me, which is basically using TouchOSC to act as a virtual midi port, rather than one I created in apple audio midi setup.
Now I think this is just a straight up bug in cubase, not correctly working with apples virtual midi ports (But since I was planning to use TouchOSC anyways, I don’t really mind also using it as a replacement virtual port)
@robw I think I need to figure out now, how to reprogramm your script to search for TouchOSC Bridge rather than Icon CC as secondary port.
I think this is code I need to change (from icon_elements.ts), but doesn’t the v3_beta remote also ask for an Icon CC Input port? Is that also defined somewhere?
the makeDetectionUnit call doesn’t work so well in this case and it always works as a Port Pair - so you get both input and output even though for the MIDI CC you only need one of them (anything going back to the Platform M+ as midi feedback needs to go to its midi port, not a virtual midi port).
For this use case MIDI Remote API needs a mmakeDetectionUnit that only find the single output port.
I’m not surprised it doesn’t support that use-case, we are clearly leveraging this facility in a different way to the core intent.
So yes you are looking at the right spot, but its “weird”. MIDI Remote will fallback to asking you to put in the port pair as a result.
