MIDI Remote - Defects & Lesson Learned

All changes using the mouse


1 Like

This is said so nicely. In our C4 script, none of the changes made from GUI/mouse worked, except the Pan setting. I have a theory for this.

This is a really interesting part. So mOnValueChange also trigger mOnDisplayValueChange too? Like two calls at once? What happened exactly to your subPages, do they entirely stopped working or they dont work properly? What do your subPages do normally?

For our C4 script, we really need a working mOnDisplayValueChange and i would not like to do it, like you did it now. I am happy that you found this solution, but doing this for value ranges of 0-127 would be a nightmare and this many times for different cases. I also assume that you will get in trouble if you try to do this. My experience with the floating point numbers is not good.
The Filtertype selection in your script use bigger steps, but i am sure as soon as those steps become smaller by using i.e. a range of 0-127, that you will have unpredictable results.

What i mean with this is, you will have different values for the same case/situation. I believe this comes from rounding errors of the floating point numbers. This leads to the same thing, you described me as “sometimes a value is offsync by a value of one”, but the reality is even worse. It is more like "sometimes it is one and sometimes it is two and sometimes (this is the best :joy:) it is both. This is my experience with Pan settings and edgy values for LED segments of the LED ring and this absolute not acceptible for me. It is kind of a gambling game and we could bet on which LED segment will turn on at a value of “L70” for example. Will it be segment two or three, no one can predict this to 100% :rofl: It will always be a random thing. How is that possible, if it is not caused by rounding errors?

I thought there would be problems with edge conditions as well, but so far its working remarkably well. I still need to figure out the frequency mapping however. And even then it might be slightly off. But even if it is, i don’t think it would be a big deal. I was more concerned about the filter type, but it seems to be spot on.

Now if Steinberg decides to change the mapping in the future, there will be problems.

I can not find anything for mOnValueChange. It does not exist in API index. It only exist in midiremote_api_v1 code and there it is used for Surface → to Hostbinding. There is setSubPage found too and maybe that is why your subPages stopped working.

Ron.Garrison can you please answer me this?

The displays need bi-directional feedback like the LED-Rings of a encoder, right?
What is, if mOnDisplayValueChange is used for “from controller to Cubase” and mOnProcessValueChange is used for “from Cubase to controller” to enable bi-directional feedback for the displays?
Would that make some sense?

It would make to me, because it would explain why something like


  • mOnProcessValueChange : function (activeDevice : ActiveDevice , activeMapping : ActiveMapping , value : number )
  • mOnDisplayValueChange : function (activeDevice : ActiveDevice , activeMapping : ActiveMapping , value : string , units : string )
  • mOnTitleChange : function (activeDevice : ActiveDevice , activeMapping : ActiveMapping , objectTitle : string , valueTitle : string )
  • mOnColorChange : function (activeDevice : ActiveDevice , activeMapping :
    ActiveMapping , r : number , g : number , b : number , a : number , isActive : boolean )

has these properties. They all have to do with bi-directional feedback.
Maybe we need them, to avoid infinity loops.
What do you think?

@u-man, I think this is why the subpages stop working when I try mOnValueChange. I need to do some more testing on this by trying what @oqion suggests.

1 Like

Good to know these are not yet implemented, as that was one of the things I was missing from the Generic Remote.
Any idea when they will be implemented?