Very interesting, thank you for the detailed reply! Skimming through the forum I found some posts by @Shor who also thinks this is an issue with rounding, so you’re probably on to something.
So I guess this could be fixable with scripting somehow, at least if you know how to program in the first place. Time to learn some JavaScript, I guess…
Unfortunately not, only normal midi messages as far as I can tell.
Sorry , ican’t resist , i tried but 
What you actually mean by this statement is you cannot complete FULL midi remotes as there are some many features still broken , like endless encoders
Honestly it’s not that, I just find myself pissing about with controllers and creating the ‘perfect’ workflow and forget to do music a lot of the time. I’ve never even done an album that is my own in all these years - i’ve reached the point of being more shamed of that, than me not having a fully working MIDI remote. 
It’s a disgrace really, so i’m making a conscious effort to remain more focused on what I love rather than the tools I use. i.e. It’s more beneficial to sit playing an acoustic guitar and coming up with chords than it is hunched over a laptop, or writing JS in the remote API.
I even started looking at the bloody Stream Deck Plus after reading this thread, looks a nice piece of gear and has me aroused - So I just shut the web browser tab down. Paypal buy in 3 doesn’t help either.
Apple took all my money black friday! lol
You have been reading my mind, including the pay in 3 ahaha .It’s a pity , these look so good so , Steinberg still has a long way to go with the MR app ,
I’ve taken to reverting to the Generic Remote for the time being, since it doesn’t seem to have this bug.
The other potential work-around is more problematic. Sending relative CC messages doesn’t work right on all controllers. For example, Native Instruments controllers send the relative CC ok, but don’t react to receiving the regular CC in that mode, which is absolutely crucial. Behringer’s ancient BCR2000 gets it right, sending relative CC and in that mode reacting to incoming regular CC to set it’s light rings.
Thanks to @mlib for making me double-check. The following is no longer true and using relative CC mode should work fine for those controllers that work well with it. Sorry about having posted something that’s clearly outdated…
In addition, sending relative CC is problematic with some plugins, since that mode makes them stop being in logarithmic mode for some parameters like EQs or Filters that go from 50 to 20KHz. A relative CC may change the frequency by a single Hz. That’s maybe ok in the very low frequencies, but totally impractical at the high end.
Yup this looks exactly like the same bug I have talked about in plenty of threads.
I think @Jochen_Trappe replied to me in one thread thanking me for reporting it.
It seems surprisingly difficult to fix, and I admit I am disappointed it is still not fixed in this update.
I made a generic script to work around it that I used for my own controllers but it not ideal, as using the remote editor would’ve been so much nicer.
However until this bug is fixed it’s a no go for any controller where you want midi to be sent back to your hardware.
The actual bug is that cubase does not round values to an integer, but simply casts it which literally just means the decimals are removed without rounding to the nearest integer.
Hi Jochen,
That workaround doesn’t help for the situation of motorized faders at all.
And it also doesn’t help for enabling the better hardware remotes that can display current values numerically or with LED displays.
This really should be a high priority fix.
Isn’t it possible to just NOT echo incoming CC messages to the sending device (but still to all the others?) while in absolute mode? – While in relative mode, we would still need the echo to the sending device.
p.s. The Generic Remote doesn’t have this problem, so it would seem to be entirely possible to make it work within Cubase?
I agree 100%
This is something that worked perfectly before. The feedback problems as well as rounding errors is causing the new midi remote editor to be impossible to use for certain controllers.
I think that’s an additional problem. But the other issue is that the incoming absolute CC message gets echoed to the sending device with some latency.
Specifically: My sending controller may have already sent 80, 81, 82, 83 it ends up receiving the first 80 from the MIDI Remote after having sent the 83. So now the sending controller is back to 80, rather than at 83. And as I keep turning, now dutifully my controller sends 81,82,83,84 while Cubase may still echo some of the original remaining 81,82,83 somewhere intermingled - therefore continually setting my controller back in time a few values.
I’ve confirmed this via midi monitoring (and posted my output in one of the very early threads about this).
The rounding issue you’ve discovered compounds the weirdness.
Can you back this up with something?
AFAIK, no plugins knows what MIDI CC mode your controller is in when using MIDI Remote (or Generic Remote for that matter). My understanding is that MIDI Remote is an abstraction layer on top of an already existing abstraction layer (which would be Cubase treating any VST automation parameter value as normalized floating point values 0-1).
In your example with an EQ, it shouldn’t matter if you use a traditional 0-127 value MIDI CC or a relative encoder. It is handled by Cubase, not the plugin itself. The plugin should still receive values between 0.0 and 1.0.
I’ve done some testing with the MIDI Remote API and relative MIDI CC encoders and I found that the issue is not as simple. The feedback values does not come back as integers, they come back as floating point, but not the same decimal value as was being sent.
Thanks for making me dig into that again.
It was quite a long time ago when I bumped into this issue, and I had not re-checked recently.
Your observation is correct and I’ve amended my prior post.
Thanks again!
The generic remote used to have issues with send and receive too, as I had to create a separate GR device for incoming and outgoing to make sure that they didn’t clash. this was with an NI S49 Mk2.
So it’s not perfect either. Damn, this is remote 101 isn’t it?!! lol
Ok, so I’m most certainly missing something because this seems a bit too easy, but at least from my experiments so far I seem to have this working now.
All I really did was disable the hardware feedback by removing .setOutputPort, and instead create a function that ‘manually’ sends midi on value changes (but first rounds the value with Math.round, thanks @Shor).
Again I feel I must be missing something which will cause problems with this, because it’s such an easy solution, but for now it seems to work perfectly: no rubberbanding (except around the 0db mark, but this seems to be a feature?!), values in Cubase and on the Stream Deck stay perfectly in sync, and switching between tracks also correctly updates my values on the Stream Deck.
var midiremote_api = require('midiremote_api_v1');
var deviceDriver = midiremote_api.makeDeviceDriver('Elgato', 'Stream Deck Plus', 'Lucas');
var midiInput = deviceDriver.mPorts.makeMidiInput();
var midiOutput = deviceDriver.mPorts.makeMidiOutput();
deviceDriver
.makeDetectionUnit()
.detectPortPair(midiInput, midiOutput)
.expectInputNameEquals('StreamDeckPlusOut')
.expectOutputNameEquals('StreamDeckPlusIn');
var page = deviceDriver.mMapping.makePage('Default');
var hostSelectedTrackChannel = page.mHostAccess.mTrackSelection.mMixerChannel;
function createKnob(midi_channel, midi_cc, x, y, w, h, hostValue) {
var knob = deviceDriver.mSurface.makeKnob(x, y, w, h);
knob
.mSurfaceValue
.mMidiBinding
.setInputPort(midiInput)
.bindToControlChange(midi_channel, midi_cc);
page.makeValueBinding(knob.mSurfaceValue, hostValue);
knob.mSurfaceValue.mOnProcessValueChange = function (context, newValue) {
midiOutput.sendMidi(context, [176 + midi_channel, midi_cc, Math.round(newValue * 127.0)]);
};
}
createKnob(0, 1, 0, 0, 1, 1, hostSelectedTrackChannel.mValue.mVolume);
createKnob(0, 2, 1, 0, 1, 1, hostSelectedTrackChannel.mSends.getByIndex(0).mLevel);
createKnob(0, 3, 2, 0, 1, 1, hostSelectedTrackChannel.mPreFilter.mGain);
It’s not simple, but I actually made a script that handles this, and it should be shared somewhere on these boards
I did a script that has some rudimentary functions for creating faders/knobs etc.
But I think your problem is actually that you have some other possibly higher resolution control adjusting your values?
As far as my monitoring and tests went, I was having Cubase return the same floating point values as I sent, so I managed to get around this problem entirely with my script. It’s also not necessarily super important that you get back the exact same decimal value. The most crucial point (that Steinberg is missing out on) is that a given integer that converts to a 0.0-1.0 float value should always be able to convert back to the same integer. Just using round solves this.
Again, I did solve this in my own scripts for my controllers, but there are sacrifices, as I had to omit some support for parameter scaling and jumps in order to get around the midi feedback bug.
It should work at least decently as long as you don’t start using a second or more midi controllers mapped to the same things. That’s where it may get tricky.
I can’t think of any reason why I would want to do that in my setup right now, so fingers crossed that this will hold.
I gotta say though that I really hate having to configure my whole setup with code now instead of just using the great surface editor, so hopefully this will be fixed as soon as possible (and I really do not understand why this is still a problem in the first place if it is a known issue since more than a year 
).
Even if you create a surface in the API, you can still create pages within the surface editor once it’s running in Cubase. It’s a bit tricky when you have manipulations in place though.