Later today, I will try out the 0x90+Channel midi commands and see whether they work as expected here, and let you know.
A final question. When should this function get triggered? Is it upon the device’s activation or on a later stage upon a page or subPage activation?
For example, when I change a subpage, this sometimes changes the colors of several buttons. There are many places (= 241 in the version I am currently working on) in the script where I change the colors, e.g. whether a button is pressed or just released.
I’m having one slight issue. I al;ways use re-record so hit the Record button, make a mistake, hit it again and Record again. When I hit the Record button Cubase stops now instead of re-recording.
After loading the script, the Pan LED lights up a little weaker than in Cubase 12.
When I then press the scroll button, it does not light up.
Is this the same for you?
I have now checked what the new Cubase MIDI monitor does and what it is supposed to send.
It looks normal and there I can also see the command to switch On the scroll button LED. Nevertheless, the scroll button remains dark.
I now have the more feeling that the FaderPort is being initialized incorrectly by Cubase.
When I try Cubase 13 with an old script (January 2023) I have the same issues.
System: Windows 10 - 22H2
The colours are working here. C13 iMac 2019 Ventura 13.6.1.
Scroll lights up and I don’t think there are any differences from C12.
The colours are working here. C13 iMac 2019 Ventura 13.6.1.
Scroll lights up and I don’t think there are any differences from C12.
And what color has your Channel Button now when you’re in the Mode activate knob value under mouse ?
Hi, I think I found the problem based on the example you earlier gave for rgb, and I’m sorry I’ve missed correctly reading your variables. You see, you have the 0xF0 inside the example you’ve sent. The 0xF0 is not allowed in the MIDI 1.0 and in the midi note message, since it exceeds the 0x7F limit. Now, in CB12 there’s a logical “and” performed internally which handled this misuse. However, in CB13, and I have to guess this is because it will eventually comply with the MIDI 2.0 standard, no logical and is performed. This leads to the 0xF0 properly sent as a second message, and breaks things.
Generally, you should limit the variables sent to the 0x7F limit.
Please have a look at this tested snippet:
var midiremote_api=require('midiremote_api_v1')
var deviceDriver = midiremote_api.makeDeviceDriver('Test Devices', 'A test Device', 'Someone')
var midiInput = deviceDriver.mPorts.makeMidiInput()
var midiOutput = deviceDriver.mPorts.makeMidiOutput()
deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
.expectInputNameContains('BMT 1')
.expectOutputNameContains('BMT 2')
var surface=deviceDriver.mSurface
var aButton=surface.makeButton(0,0,1,1)
aButton.mSurfaceValue.mMidiBinding
.setInputPort(midiInput)
.bindToControlChange(0,20)
var aPage=deviceDriver.mMapping.makePage("aPage")
var aDummyVar=aPage.mCustom.makeHostValueVariable("aDummyVar")
aPage.makeValueBinding(aButton.mSurfaceValue,aDummyVar).mOnValueChange=function(activeDevice,activeMapping,value,diff){
midiOutput.sendMidi(activeDevice, [ 0x91, 0x36, 0xF0])
//midi values should max out to 0x7F. Here we have the 0xF0 value which is out of the valid range.
//In CB12 an internal "and" is performed, so for example the 0xF0 is sent as 0X70 since CB12 performs (0x70 AND 0x7F)
//In CB13 no "and" is performed and I suspect this has to do with MIDI 2.0 which does accept much bigger values. This way, the data are no longer consistent, because they're not following the MIDI 1.0 protocol
//Please logical "and" the r,g,b values to the 0->0x7F range
//For example:
midiOutput.sendMidi(activeDevice, [ 0x91, 0x36, 0xF0 & 0X7F])
//This one will work as expected
midiOutput.sendMidi(activeDevice, [ 0x92, 0x36, 0x20])
//This one since is in the valid range will output correctly
midiOutput.sendMidi(activeDevice, [ 0x93, 0x36, 0xF0])
//This again will not work properly
}
2 Likes
I think you’re right, m.c. 
I also just had another look to the explanations of the MIDI implementation of the FaderPort and it says to the control of the RGB colors:
cc = 7-bit color value
This clearly means a range from 00 to 7F.
I will now try to implement my colors with this range.
Best regards
CKB
Exactly.
Here’s a list I’ve converted for 7-bit usage:
var colors={
black: [0,0,0],
white: [127,127,127],
red: [127,0,0],
lime: [0,127,0],
blue: [0,0,127],
yellow: [127,127,0],
cyan_aqua: [0,127,127],
magenta_fuchsia: [127,0,127],
silver: [96,96,96],
gray: [64,64,64],
maroon: [64,0,0],
olive: [64,64,0],
green: [0,64,0],
purple: [64,0,64],
teal: [0,64,64],
navy: [0,0,64],
dark_red: [69,0,0],
brown: [82,21,21],
firebrick: [89,17,17],
crimson: [110,10,30],
tomato: [127,49,35],
coral: [127,63,40],
indian_red: [102,46,46],
light_coral: [120,64,64],
dark_salmon: [116,75,61],
salmon: [125,64,57],
light_salmon: [127,80,61],
orange_red: [127,34,0],
dark_orange: [127,70,0],
orange: [127,82,0],
gold: [127,107,0],
dark_golden_rod: [92,67,5],
golden_rod: [109,82,16],
pale_golden_rod: [119,116,85],
dark_khaki: [94,91,53],
khaki: [120,115,70],
yellow_green: [77,102,25],
dark_olive_green: [42,53,23],
olive_drab: [53,71,17],
lawn_green: [62,126,0],
chartreuse: [63,127,0],
green_yellow: [86,127,23],
dark_green: [0,50,0],
forest_green: [17,69,17],
lime_green: [25,102,25],
light_green: [72,119,72],
pale_green: [76,125,76],
dark_sea_green: [71,94,71],
medium_spring_green: [0,125,77],
spring_green: [0,127,63],
sea_green: [23,69,43],
medium_aqua_marine: [51,102,85],
medium_sea_green: [30,89,56],
light_sea_green: [16,89,85],
dark_slate_gray: [23,39,39],
dark_cyan: [0,69,69],
aqua: [0,127,127],
cyan: [0,127,127],
light_cyan: [112,127,127],
dark_turquoise: [0,103,104],
turquoise: [32,112,104],
medium_turquoise: [36,104,102],
pale_turquoise: [87,119,119],
aqua_marine: [63,127,106],
powder_blue: [88,112,115],
cadet_blue: [47,79,80],
steel_blue: [35,65,90],
corn_flower_blue: [50,74,118],
deep_sky_blue: [0,95,127],
dodger_blue: [15,72,127],
light_blue: [86,108,115],
sky_blue: [67,103,117],
light_sky_blue: [67,103,125],
midnight_blue: [12,12,56],
dark_blue: [0,0,69],
medium_blue: [0,0,102],
royal_blue: [32,52,112],
blue_violet: [69,21,113],
indigo: [37,0,65],
dark_slate_blue: [36,30,69],
slate_blue: [53,45,102],
medium_slate_blue: [61,52,119],
medium_purple: [73,56,109],
dark_magenta: [69,0,69],
dark_violet: [74,0,105],
dark_orchid: [76,25,102],
medium_orchid: [93,42,105],
thistle: [108,95,108],
plum: [110,80,110],
violet: [119,65,119],
orchid: [109,56,107],
medium_violet_red: [99,10,66],
pale_violet_red: [109,56,73],
deep_pink: [127,10,73],
hot_pink: [127,52,90],
light_pink: [127,91,96],
pink: [127,96,101],
antique_white: [125,117,107],
beige: [122,122,110],
bisque: [127,114,98],
blanched_almond: [127,117,102],
wheat: [122,111,89],
corn_silk: [127,124,110],
lemon_chiffon: [127,125,102],
light_golden_rod_yellow: [125,125,105],
light_yellow: [127,127,112],
saddle_brown: [69,34,9],
sienna: [80,41,22],
chocolate: [105,52,15],
peru: [102,66,31],
sandy_brown: [122,82,48],
burly_wood: [111,92,67],
tan: [105,90,70],
rosy_brown: [94,71,71],
moccasin: [127,114,90],
navajo_white: [127,111,86],
peach_puff: [127,109,92],
misty_rose: [127,114,112],
lavender_blush: [127,120,122],
linen: [125,120,115],
old_lace: [126,122,115],
papaya_whip: [127,119,106],
sea_shell: [127,122,119],
mint_cream: [122,127,125],
slate_gray: [56,64,72],
light_slate_gray: [59,68,76],
light_steel_blue: [88,98,111],
lavender: [115,115,125],
floral_white: [127,125,120],
alice_blue: [120,124,127],
ghost_white: [124,124,127],
honeydew: [120,127,120],
ivory: [127,127,120],
azure: [120,127,127],
snow: [127,125,125],
dim_gray_dim_grey: [52,52,52],
gray_grey: [64,64,64],
dark_gray_dark_grey: [84,84,84],
light_gray_light_grey: [105,105,105],
gainsboro: [110,110,110],
white_smoke: [122,122,122]
}
In your list there are some very amusing color names… 
Thanx, m.c
By the way:
The correction was actually very simple.
After adjusting the upper nibbles in the RGB definitions like this:
8 > 0
9 > 1
A > 2
B > 3
C > 4
D > 5
E > 6
F > 7
the colors are now exactly the same as with Cubase 12.
Also with Cubase 12 the script with these adjustments runs just as before.
I have no idea, just compiled them from 255 to 127 as found on the net 
I think Cubase 13 has made a few changes to the preferences.
Yes, I can confirm that.
I think Steinberg will fix this problem pretty quickly with the first update patch.
I could fix this problem now, but that would result in two script versions (one for Cubase 12 and one for Cubase 13).
It is light pink when I’m in the Mode activate knob value under mouse
1 Like
Thanks, hegerber. That’s how it should be.
No it must be the script. If I use the NUMPAD asterisk key to start recording, then hit it again, it erases my take and restarts recording properly.
If I do the same with the Faderport record button, it erases my take and then stops and doesn’t initiate re-record.
Hi all,
here comes an update, in which two problems with Cubase 13 have been fixed:
- Problems with the Button LED colors for some cases (wrong color or no color).
- The problem with the Insert Marker function for the Marker Mode and the Hitpoint Mode.
The fix was done in a way that the script is compatible with Cubase 13 and still with Cubase 12.
20231109_PreSonus_FaderPort.zip (38.5 KB)
The update only consists of the script file PreSonus_FaderPort.js
The bigger update with the new extensions comes later.
Best regards
CKB (Christian)
4 Likes
Thank you all for figuring it out!
2 Likes
Much appreciate, Christian! Outstanding work!
1 Like
This is strange, because the script only ever activates the standard Cubase recording function.
I have tested the following:
- creating a new empty track
- at the beginning of the track: press Record Button on the FaderPort
- recording something while the cursor is running
- press Record Button on the FaderPort
= then afterwards, the track is not stopped and the cursor continues to run in Play Mode - press the Record Button on the FaderPort
= then afterwards, the track is not stopped and the cursor continues to run in Record Mode - now I can record something new. So nothing is stopped here.
After all I can see the recording snippets next to each other with pauses in between.
Is this different when do the same or do you mean something else?