Hi,
What exactly do you mean by this?
Do you mean, that if the track is selected in Cubase, the Auto Bank doesn’t show the selected track (and surrounding tracks) on the hardware?
Hi,
What exactly do you mean by this?
Do you mean, that if the track is selected in Cubase, the Auto Bank doesn’t show the selected track (and surrounding tracks) on the hardware?
Global track scroll is a function in the Faderport script made by ckb where you can scroll through the tracks using the Faderports knob. This function is broken in the new update.
Hi,
It would be interesting to hear from the script author to know, how he implemented it, to be able to investigate, what happened.
CKB,
we are missing you so bad
Carlo
I think the author CKB will answer here as soon as possible and look in the script where the track scroll problem with the cubase update 13.0.50 occurs.
Question: If I now upgrade to Cubase 13.0.50 and have the same problem like heggebugg, can I simply then revert to Cubase 13.0.41?
Hi,
If you are on Windows, you can uninstall the update by using the system (Windows) uninstaller.
If you are on a Mac, you need to have the Cubase 13.0.41 installer, delete the Cubase 13 application, and install Cubase 13.0.41.
Hi,
i am on windows 10 and have updated Cubase and Nuendo to the latest Versions 13.0.50 each.
With an older Faderport srcript i had problems in 13.0.50, but using
the Script from the Post 2024 February, third from CKB in this topic
" CKB - new update available - January 31, 2024"
Here the complete new zip-file (all files inside are new):
fp-wizard_20240131.zip (2.9 MB)
everything works well with my Faderport 2 (Studio One Mode) in 13.0.50!
I had to copy the “PreSonus_FaderPort.js” manually to the following folders:
C:\Users\Heiko\Documents\Steinberg\Cubase\MIDI Remote\Driver Scripts\Local\PreSonus\FaderPort
C:\Users\Heiko\Documents\Steinberg\Nuendo\MIDI Remote\Driver Scripts\Local\PreSonus\FaderPort
For track scrolling (up and down) via the jog wheel enable the white channel button
I hope, that helps.
Best
Heiko
Global track scroll is the function where you can scroll the tracks by holding the loop button and scrolling with the knob wherever you are in the script. Neither that or the scrolling on the channel page works anymore on my system. It seems to scroll randomly up and down. I’m on a mac.
Hi Martin,
the script works in such a way that within the track selection turning the knob works with the following command bindings
‘Project’, ‘Select Track: Prev’
and
‘Project’, ‘Select Track: Next’
I was able to reproduce the issue; it also exists in Windows. The previous (next) track of the current project is not always selected, but sometimes but not always some random track.
Before - these command bindings had never caused any problems since the very first version of this script.
Perhaps you could create a code snippet yourself and try out these command bindings on a test project…
Best regards
CKB
Hi @CKB,
Thank you for the reply. Can you reproduce it also if you assign the commands to the buttons? Or do you think it might be related to the fact, that the encoder sends multiple values?
Hi @CKB, just made the following test remote, and works as expected here. What I did notice was that based on my knob’s turn (I set it to an absolute 0-127 range) this process can be very fast. Maybe this is causing the impression of randomly selected tracks? Unfortunately I don’t have a FP so I can have a look at the issue myself too
var knob=surface.makeKnob(0,0,1,1)
knob.mSurfaceValue.mMidiBinding
.setInputPort(midiInput)
.bindToControlChange(0,24)
var knobLeft=surface.makeCustomValueVariable("knobLeft")
var knobRight=surface.makeCustomValueVariable("knobRight")
var page=deviceDriver.mMapping.makePage("page")
knob.mSurfaceValue.mOnProcessValueChange=function(activeDevice,value,diff){
if(diff<0 || value==0){
knobLeft.setProcessValue(activeDevice,1)
} else {
knobRight.setProcessValue(activeDevice,1)
}
}
page.makeCommandBinding(knobLeft,'Project', 'Select Track: Prev')
page.makeCommandBinding(knobRight,'Project', 'Select Track: Next')
Hi Martin,
I have now searched again. Now I think it’s not the API commands themselves.
There seems to be a strange problem with the value binding in Cubase 13.0.50, which Cubase 13.0.41 still worked.
The FaderPort has only ONE encoder, for which a custom variable is defined in the script.
When I use this custom variable to scroll in the tracks, I check a value change in the mOnProcessValueChange handler. This worked fine in Cubase 13.0.41.
When I debug in the script there with the following, I see the movement of the encoder.
console.log('prev_Rotary = ' + prev_Rotary.toString())
console.log('value = ' + value.toString())
prev_Rotary = value
With Cubase 13.0.50 the phenomenon occurs (but not always) that the handler mOnProcessValueChange is fired, but the value has not changed or it hangs between two values. This happens even if I turn the encoder very slowly. Sometimes everything works again for a while.
thanks m.c,
the interesting question is also, what could it be that is different in Cubase 13.0.50. Was there perhaps an update of the integrated javascript interpreter within cubase?
What is puzzling is that sometimes the error does not occur at all and then suddenly a little, then again not, then again very intensively, and so on. Only with Cubase 13.0.50.
Since this was a maintenance update, sure it may be possible that some changes occurred.
This is very interesting. I cannot replicate it here. I inspected the script a bit, I do see that there are some conditions driving to changing the kb_Rotary_Value. So perhaps a change in the API led to “strange” values concerning these conditions. Just assumptions unfortunately.
Hi,
I’m just thinking loud… Could this be related to the motorized-fader issue (or fix)?
I don’t think so.
If I remember correctly, when MIDI Remote was introduced, there was an error that when the OnProcessValueChange handler was triggered correctly after a rotation of an encoder, in a few cases the value parameter passed remained the same, i.e. it was not updated. My speculation on this: Perhaps this occurs in a very rare side effect situation again that has crept in with Cubase 13.0.50. Perhaps only a small assignment statement is now missing in the API code, but in a place that is very rarely called up.
Well… the update to 13.0.50 has been out since yesterday.
Maybe the same error will appear with another script soon.
I have now noticed that the pan function with cubase 13.0.50 also works incorrectly if, for example, I have selected the first track and still call up “track to the left”, which was not a problem before. Even after that, the binding of the encoder is obviously disturbed and pan jumps to full left (value = 0).
That means that the error is probably possible everywhere (Sends, Quick Controls, etc.) when using Cubase 13.0.50.
Last night I’ve noticed a value set to 0 to a script I’m preparing for a Keystage, when using custom vars under subpages. I didn’t pay much attention cause I thought there was something wrong in my handling since I’m in an alpha stage. But now that you’re saying this, I guess it needs a deeper look, it might not be a coincidence after all. My first step will be to check if I see different behavior under CB12.
A very well come back Mr. CBK
Carlo
Value under mouse has erratic behavior too. I rolled back to 13.0.41.