You may be right. Just day before I found a mention about this thread on Reddit I created a ticket on Presonus site after I was confused with 8-track-Mackie nonsense for my FP V2 in Cubase, because I thought it can’t be this way, something is definitely wrong! An assistant offered me to update BIOS and all my devices drivers as a solution to make FP follow the track selection outside of the 8-track range, like it does in Studio One… The thing is I know that this is a BS soluition, he knows that too! And is stillwasting customers time and pretending that Presonus is not who intentionally made it work badly in Cubase and flawlessly in Studio One. So I replied that his solution is not working, sent the link to this topic and advised them to pay or hire you, as you apparently have much better idea how to make it work properly… crickets 
Hi @WEM . First of all, what an awesome job you did on the script!!! Much appreciated.
One question; I don’t know if I’m the only one who thinks that hearing the motorized fader working, sometimes can be annoying while producing. With every channel you switch, you hear the Faderport fader make a sound, re-adjusting to the volume fader position.
Is there any way that I can temporarily bypass the Fader following the volume position of the channels? Just so that I don’t hear the fader constantly jumping from one position to the other.
Is there any way that I can temporarily bypass the Fader following the volume position of the channels? Just so that I don’t hear the fader constantly jumping from one position to the other.
That sounds interesting to me too.
Could it perhaps be set up, so that, for example, “Shift + Bypass” as a mode would have the consequence, that the fader would then not correspond with the channel volume? 
I often find myself stepping through the channels, adjusting something, but not the channel volume. Then the noise from the fader also bothers me a bit.
This would also increase the lifetime of the motorized fader.
This is a very interesting idea I never was thinking about.
It was not difficult to implement, so you can find the update with the requested function already on my homepage (PreSonus Faderport (2018) and Steinberg Cubase 12 (Update) - wem-music.de).
best wishes
Werner
@WEM You Are Awesome !!! hahaha 
Thank you so much for adding this function. I can imagine a lot of people using it. 
Keep up the good work!
Just tested the new update. 
5 coffee on me buddy! 
@WEM
I tested the new update too. - It’s perfect!
Thank you very much. 
P.S.:
I find it very good, that I can still use the motorized fader in Shift+Touch -Mode and that only the motorized update of the position is switched off when changing channels.
Strange behaviour to report.
A few times now a project has lost focus with the “master volume” option for the rotary controller.
All other buttons appear to work and if I open midi remote page in Cubase I can see the button press of master volume is being received.
Open a new blank project and master fader works. Import tracks and pool etc from non working project and all is OK.
I wouldn’t really highlight this but it has occurred more than once.
I also note that if focus is on “master volume” then shift is activated, upon return the volume is not the same. I have found it to return higher. Wonder if this is related.
Thx for the report. I will look into that issue…
br
Werner
I think the problem, that connymcc described, is here:
This code part:
if ((var_newvalue > 0.783) && (var_newvalue < 0.795))
middleButtons.kb_Rotary_CRLevelValue.setProcessValue(context, 0.789086580276489)
else
middleButtons.kb_Rotary_CRLevelValue.setProcessValue(context, value)
should be replaced by:
if ((var_newvalue > 0.783) && (var_newvalue < 0.795)) {
middleButtons.kb_Rotary_CRLevelValue.setProcessValue(context, 0.789086580276489)
middleButtons.kb_Rotary_Val.setProcessValue(context, 0.789086580276489)
} else {
middleButtons.kb_Rotary_CRLevelValue.setProcessValue(context, value)
middleButtons.kb_Rotary_Val.setProcessValue(context, value)
}
best regards
CKB
This is also correct but not the root cause for the issue here.
The issue is comming from the hack to reactivate / restore the last active function when returing from shift to normal mode. 
I work on a different solution.
Update: As for now I give up. I can localise the issue 100% but I can’t solve it. Only workaround is to temporarily deactivate the restoring of the pages when switching to shift and back.
Hi WEM,
I have been working on your script from 14.01.2023 with success.
With the changes I made, it just worked, that the master volume (CRLevel) does not change, when switching to Shift and back to Normal. At least, according to my last tests, it looks, that it runs stable.
In your code, the lines, that I changed or added, now are commented with ‘// CKBa’.
To be able to debug better, I have inserted a number 001) … 052) in each console output at the beginning. Maybe this is also useful for you.
Best regards
CKB
( Note: I have removed the upload here, because a newer update from WEM is availabe on his website. )
Hi CKB,
thank you for finding this workaround. I played with the same concept but reset the value on a different location. Unfortunately without success.
This whole thing is with restoring the previous function when switching between shift & normal page is a compromise and workaround. If you look at the logs you can see that the callbacks are called multiple times and there are some strange things ongoing
I hope Steinberg introduces better possibilities here.
I mixed our two files (I did some small changes too) and compiled a new release with can downloaded from my page as usual (PreSonus Faderport (2018) and Steinberg Cubase 12 (Update) - wem-music.de)
best regards
Werner
If you look at the logs you can see that the callbacks are called multiple times and there are some strange things ongoing
Hi WEM,
yes, I have also seen, what all was displayed in the logs: too much! I don’t understand, why this is happening. Is it the FaderPort?, the programming?, the OS?, the API? I have no idea. Maybe Steinberg wrote the API this way, because some other hardware can be unreliable and does, what it should, only after a second triggering?
I noticed, while I was watching the logs, that the wrong value, that CRLevel had received, was exactly the PAN value. Hm, maybe, because the simultaneous linking of the Rotary knob with the CRLevel and the PAN value does not work stable and therefore there is a back and forth retriggering? I think it will clear up in some time…
But - Your current version seems to run stable. And that’s great!
Addition: Or maybe Steinberg made some workarounds in their API because there was not enough time to finish the implementation of the API until the release date. We will see it in Cubase 13, how big the heap of logs then is… 
What can I say. Perfection. Thanks once again.
Hi WEM,
I’ve seen, you removed the extra-lines, that begin with
middleButtons.kb_Rotary_Val.setProcessValue...
Without these lines, in a (very) few cases, the knob does not work correctly here. When I turn PAN to a direction, in a (very) few cases, the value goes to the other direction or stays at the same point.
But sometimes while a full session or for a hundret times, there is no such error.
I inserted these lines (7 positions in the script) again here, and since after that, I had no such errors.
It is strange, because it looks like, that the object “middleButtons.kb_Rotary_Val” sometimes wants to be the boss and retriggers PAN or CRLevel automatically in a strange way. To prevent this, I inserted the extra-lines just behind, where PAN or CRLevel is set.
I think, you removed the lines, because you maybe had no such errors, or on your system they a more rare than here, and - of course - then it is better to remove everything, that produces unnecessary traffic.
Hi CKB,
I haven’t actually observed your described issue on my system.
What I saw is that the (or my - I actually have only one to test) Faderport sometimes skips or sends wrong values or doesn’t even send midi messages at all when turning the knob. I can clearly see and reproduce that by monitoring the midi messages. Could may be a topics of the potentiometer or how the potentiometer is impemented in the Faderport firmware. But could also a production tollerance issue of my single faderport.
In my case it’s cleary not a Cubase / Midi Remote API topic.
The additional line middleButtons.kb_Rotary_Val.setProcessValue... does kind of a double or force set of the value. This should be not needed when assuming everything works properly.
If there are cases of issues with that I will / can add the line again. I was not aware of this.
Regarding the overall performance and maintainability I think about a major restructuring of the script. I began small and it went big in the while. There are some concepts and structures inside that don’t make me happy.
But actually I tend to wait a bit and look what comes new from Steinberg that may makes some things unnecessary.
br
Werner
Yes.
Another possibility, which I could imagine as a source of errors, would be, that in the operating system (Windows) a kind of cashing takes place, that Steinberg has not yet fully got under control. If data gets stuck somewhere in the pipeline between the application and the controller, the typical programming workarounds are “multiple triggering”.
So waiting to see, what Steinberg delivers next - I also think, that makes the most sense.
best regards
CKB
Controlling the volume and panning of MIDI Tracks doesn’t seem to work for me. Neither receiving Does anyone else have that problem? Works for all other track types (including Software Instrument tracks)
With the CC121 and Eucon-controller, midi tracks can be controlled that way.
EDIT: Sorry, I see now it’s in the original list. I still use Nuendo 12.0.40, are there any updates to that functionality in later versions?
The midi-remote does not support midi tracks yet. Sounds odd, but is true.