MIDI Remote fundamentally changed after Version 12.0.52?

[santiagoa]

Hey everyone,
first post Im getting very specific here. I didnt find infos anywhere. Hope some of you cracks can give me advice!
I have a Presonus Faderport 8 and wrote with lots of efforts (and less programing skills:stuck_out_tongue: ) a script for MIDI Remote. To be fair, my program logic is quite complicated and I tried to mimic the behaviour of the Faderport in Studio one–> as nice as it can be!!
but, I managed to achieve it and I was surprised that it worked and was very happy working with it.
yet,
it only worked till Cubase version 12.0.52.
with the versions that came afterwards (with so called “improvements”) it didnt work as good. Just some things functioned and most of all, all kind of “interruption-sub-calls” didnt work any longer…
so I sticked to version 12.0.52 till I, few days ago, decided to give it a try to Cubase 13. Somehow I was thinking the bugs were going to be fixed?
But not the case. Funny enough, my MIDI remote works there better than in the versions in between. However still with other kind of bugs…
Now, I assume by now it is my bad. Cubase is fixed, just my code is too f%kd up
But if I was to recode my old script I just took a look at the definitions and its all the same, nothing changed… I see no chance to redo my code and get what I was getting in old versions…
Question:
did MIDI Remote completly change in the cubase programming?
if yes, perhaps they forgot giving some access rights to the MIDI Remote instructions whatsoever???
is there a way to compare what is different in version 12.0.52 to todays version in regards of the MIDI REmote?
Can I hope some day using my Faderport8 again, as I did before, in Cubase 13 and in the versions to come?
thanks for your supoort!

Cheers!
Santiago

[thomas_martin]

Hi,

I’m not aware of any major changes in versions after 12.0.52. in fact if I remember correctly, there was no change concerning the MIDI Remote API in 12.0.60 and 12.0.70. (maybe they fixed a bug or two)

Only improvements came with 13.0.10 whith the support of touch sensitive devices and the addition of mOnIdle callbacks.

But I see no reason why your script shouldn’t work in these versions, maybe you have a problem elsewhere.
Can you share your script so i could see if i find anything wrong?

Bests,

Thomas

[santiagoa]

Hi Thomas,
that was fast! thanks for your quick response!

sure it is very weird. I remember when programing the script i did it parallel on both my desktop and my laptop on the sofa (as relaxing activity on the evening )
And I also remember going nuts when testing the SAME script on my laptop and desktop. in the laptot as it should, on the desktop totally trash…the SAME SCRIPT!.. I took long time and frustration until I realized that I had different versions of Cubase. On my laptop the 12.0.52, on my desktop 12.0.60.
Then I just downgraded my desktop and that was it… I was happy till I decided to try C13

Perhaps you have the hardware (and muse!) to test my description above. If not you can sure have a look at my script and perhaps identify my problems.
Warning: I am not a programer and I solved my needs in some weird ways…

cheers
santiago

Presonus_Faderport8.zip (6,1 KB)

[thomas_martin]

Hi @santiagoa,

I’ve downloaded your script, and though i don’t own a faderport8, I’ve tested it with my MCU clone under 13.0.21 and 12.0.52.

First, here all faders, channel strip buttons behave correctly as well as the jog (that you assigned to bank nudge) and transport functions.

Most of your script seem to not be compatible with my controller, probably because my controller is not a full implementation of MCU.
but most importantly, I don’t see any difference when I load the script with 13.0.21 or 12.0.52.
I’ve briefly took a look at your script and don’t see why it should behave differently under different version of Cubase.

As a side note, I think at least some part of your script are a bit overcomplicated. For example, i see that you used mOnProcessValueChange on buttons to give feedback through the leds. You should be able to get the same result by using the “setOutputPort” method on the button since the LED uses the same MIDI event as the button. But both methods should work the same.

So, maybe you can give us a little more details on what doesn’t work on the latest version that were working on you previous versions.

Bests,

Thomas

[santiagoa]

Hey Thomas,
I really appreciate you take the time to help me!

ok lets get into it!

first, actually I am using my faderport in “Presonus-Modus”, not MCU, forgot to mention that, sorry… It lets me adress the surface with easy MIDI-Messages which are all listed in the manual of the faderport–> the behavior is probably quite different as the MCU.

I agree, faders, channel strips, even my insane encoder programming is working totally normal in Cubase 13–> which actually didn’t in versions 12.0.60 and 12.0.70…
And now I can recall what was my main problem with those versions–> the “.mOnvalueChange-Stuff” wasnt working at all. If you are curious you can test it yourself as I did: you can either use my code or write some dummy with an mOnvaluechange and from there then write something in the console–> it wont happen…

Anyhow… we are in 13 now and there it works!

now, after doing more intensive testing i can tell you what doenst work properly in 13 for me:

-My display update routine only works for the first channel in the bank when I navigate through the banks (only the first display gets updated). in 12.0.52. it actuallized all 8 displays at once.

-I programmed subpages for the buttons “Edit plugins” “sends” and “pan”
with those I kind of entered in a separate “scene” to control those with the faders. Whenever I pushed those in 12.0.52. then the displays where updated showing me accordingly: quick controls information, Sends, or panning status–> and the faders also updated as well and took the values accordingly. Now when I do that in 13 it doenst happen anything, first after I actively push the select button of the channel it reacts and updates all displays and faders of the bank. When I go back to track scene, then again it happens nothing, and after pushing some select button, everything in the bank gets updated.

now, writing this it is kind of a retrospective for me and I assume my script mistakes might be in those update functions? perhaps those arent properly defined and for some bug-whatever-reasons they happened to work in 12.0.52. ?? perhaps you can give me your advice there…

Finally I agree totally with you, my script is partially overcomplicated but I did what it took to, sothat this was working as I wanted it to and not getting satisfied with that what the best practices were able to provide me.
My problem with this can of object-oriented kind of thing is, it didnt work as reliable (at least back then). I remember that the LEDs switched on and remained on forever, eventhough the channels, mute or solo changed …
so i decided to go for this kind of Status variable kind of thing and tell the surface exactly what I wanted to. Yes, tedious, but I have the control over it, not the internal routines of the API script Im getting probably roasted by all programmer guys?? hahaha

Ok there you go, thats all. Again, 13 is not as bad as 12.0.60 or 120.70, but also not as good as 12.0.52 either ( in regards of the MIDI Remote for my personal script)…
I know it doesnt help, but in case you wanted me to prove my point, I could do a short video of the behaviour of the surface on both systems, let me know, I can do that…

Thank you again! I am going also to try some stuff out, now that exactly now where my problems are. Maybe I come to a solution before you can answer?

viele Grüße,
Santiago

[m.c]

Hi, the mOnProcessValueChange when we have subPages is not that reliable for updating our displays. I have some thoughts on the logic behind this, but we can leave this for another time.

A solution (one I use extensively) is to create the corresponding events, and then check inside them if we are in the proper subPage to perform updates. This means that we have to store in a key, the currently selected subPage.

Example:

Say we changed to a subPage named “mixer”. When we do this, we can set (inside the mOnActivate event of the subPage):

activeDevice.setState("subPage","mixer")

Now, say we have a control’s mSurfaceValue or a custom variable (let’s name it “control”) assigned to “mute” of the selected track, on a subPage named “mixer”:

page.makeValueBinding(control,page.mHostAccess.mTrackSelection.mMixerChannel.mValue.mMute).setSubPage(mixer)

Instead of checking the control like this:

control.mOnProcessValueChange=function(activeDevice,value,diff){
//update here - not that reliable
}

we are more safe if we do this:

page.mHostAccess.mTrackSelection.mMixerChannel.mValue.mMute.mOnProcessValueChange=function(activeDevice,activeMapping,value){
        
        var currentlySelectedSubPage=activeDevice.getState("subPage")
        if(currentlySelectedSubPage=="mixer"){

            //update here instead
        
        }
        
    }

This is my observation, I don’t know if it was broken after the 0.52 version, since I was not an early adopter of the MIDI Remote and CB12 in general.

[thomas_martin]

Hi guys,

I’ve checked a bit more on my side, and it seems to work somehow, I made a few change to be able to display thing on my controller and also I added some log on your functions “updateDisplayConfig” and “updateDisplayText”. Also I can’t switch to every subPage, but I can switch between “track”, “sends” and “pan” subpages.

• In “track” and “send” supbage, It displays the channel name. But the DisplayValue doesn’t update when moving fader.
• In “pan” subpage, only the display Value gets updated.
  updates occurs when the subpage is activated.

I’m a bit puzzled by the way you managed your displays. I see that you used a customVariable Just for updating displays. This means that you get duplicated bindings where you could have used the callback on the fader itself.
Actually, changing the callbacks from “display” to “faderValue” (l.724-747) did make the Display value work for the send subpage, but not for the track subpage. But looking at your code, it seems to be the expected behaviour.

@m.c , my experience with callbacks and subPages is that if the callback is bound to the surfaceValue, it will update on Page or subPage change without any need to use .mOnActivate. Although, I’m not sure that I used the mOnProcessValueChange. I certainly used mOnTitleChange and mOnDisplayChange though. And a thing I found nice is if i use a dummy “HostValueVariable” as binding if a control is not used on a specific subpage, it will then send a blank “title” and “value”, so my display will be cleared.

Bests,

Thomas

[m.c]

@thomas_martin

my experience with callbacks and subPages is that if the callback is bound to the surfaceValue, it will update on Page or subPage change

Yes, this is the expected and frequent behavior. However, this is not always the case. For example, you may want to try this with the focused quick controls in a subpage. Another case is when we’re scanning for the mOnChangePluginIdentity.

@thomas_martin

without any need to use .mOnActivate

I use the mOnActivate to store the subpage name. I need this for correctly displaying things in cases as the ones I’ve just described.

[santiagoa]

hey guys,
thank you!
i am overwhelmed by your answers… I mean technically
To be honest, it seems that you already know my script better than I do. I just need to get in again…
yeah, kind of recognize some of my “sins” in your comments and I try hard to remember why should I have done that…
I remember struggling with the values the direct fader binding were spiting… some kind of doubles whatever, which didnt tell me anything, i just wanted 0 or 100, not -324235 and 5423543 (those are actually found out, but you know what i mean). I guess that could explain this workaround…

Well I can tell you, I will do my homework, have a look at my script and test your recomendations (thanks again for that!). I am not really an expert and I admit I had hard time trying to follow you but I am not totally lost! I got your points! I need to get in, check your ideas, test, understand and then i can join the expert conversation,
Unfortunately, that wont happen very quick I know, but I’ll definetly let you know when and if I am could make some progress.
till then stay healthy and take care!
cheers,
Santiago

[santiagoa]

Hi again,
i have news to report:

lets begin with some extra randomness to the topic, I just found out:
I realized that the Subpage behaviour of my script actually worked when I opened a cubase12.0.52-created-project in CB13. my displays and fader where jumping whenever I pressed the subpage buttons–> nice!
and the other way around, the predicted behaviour. Cb13-created-projects opened in cb12.0.52 didnt work when jumping throug the subpages → not nice!

well I wanted to proove my point and just did from scratch the same project in CB12.0.52 and CB13 → just audio tracks, buses and stuff.
guess what? subpage behaviour worked perfectly (or lets say accordingly) in both CB12.052 and CB13 → nice
well what did I learn, what was different?
I am always using a template for mixing which I created in cb12 and modified later on in CB13… That is probably corrupt in some regards for the correct functioning of my script… I will eventually have a look on that…

lets then say, subpage behaviour is solved.
now what with display update?

when revisiting my code I was also puzzled about the display variable… no idea what i was thinking of and most of all, why and how does it work!? but anyway it does it to some degreee. I think i did this becaus I wanted my Displays to be dinamically and display lots of stuff–> i didnt want it to bind them directly to faders or buttons whatsoever…

Now, when trying to recode I realized that .mOnTitleChange wasnt really “available” for my custom variable Display (it wasnt suggested by visual studio code). which means my codeblock (line 722…728) is not, lets say, 100% correct

so I did this workaround:

    channelBankItem.mOnTitleChange=function(context, activemappig, arg2){
        if(statusTrack.getProcessValue(context)==0x7F){dUpdateTrack(context, arg2, 't')}
    }

    display.mOnTitleChange = function(context, arg1, arg2){
        //if(statusTrack.getProcessValue(context)==0x7F){dUpdateTrack(context, arg1, 't')}
        if(statusPlug.getProcessValue(context)==0x7F){dUpdatePlugin(context, arg2, 't')}
        if(statusSend.getProcessValue(context)==0x7F){dUpdateSend(context, arg1, 't')}
        if(statusPan.getProcessValue(context)==0x7F){}
        if(statusAud.getProcessValue(context)==0x7F){dUpdateAudio(context, arg1, 't')}
    } 

Now I update the titles of my display in Track-Subpage by checking the changes in the channelbankitem–>and it works–>nice!

but, why did I still keep the wrongly defined display.mOnTitleChange in there?
well for whatever reasons, this function offers me “arg2” which is the name of the variable assigned to the QuickControl in the Plugin subpage. This arg2 seems not to be available in the channelbankittem.montitleChange function…

Well guys, I think I can now say I am happy, that my script can work with cb13 the way it did with cb12.0.52.
Fundamental changes between those in regards of MIDI remote??–>definetly not! but, there is definetly some randomness in there either of us can’t explain

thank you for your time and inspiration in the topic. Without you I will surely would have need extra weeks more to get to a solution!

take care and stay healthy!
Santiago