MIDI Remote API Controller issue - DisplayValue doesn't follow automation

Cubase
, ,
1

Hi,
It’s me…again.

So while making my controller script, I ran into one slight problem.
I’m using a display on my controller to display both the track name, as well as the track volume of the selected track.

This works great while stationary, or while changing volume from Cubase or any of my controllers.
However, when I have automated my volume the “mOnDisplayValueChange” event isn’t fired. The onProcessValueChange event fires as expected, so I am receiving midi information for the value change, but seeing as we have the nice mOnDisplayValueChange i really want to make use of that.

My code for the volume display is as follows below, and it works great except for when volume is automated. I assume this is a bug?
HELP :slight_smile:

var selectedTrackVolume = deviceDriver.mSurface.makeCustomValueVariable("selectedTrackVolume")

page.makeValueBinding(selectedTrackVolume, hostSelectedTrackChannel.mValue.mVolume)

selectedTrackVolume.mOnDisplayValueChange = function(activeDevice, objectValue, valueTitle) {
	var strSysex = makeSysex(textAsArray("vl" + objectValue))
    console.log(objectValue)
	console.log("Sysex: " + strSysex)
	midiOutput.sendMidi(activeDevice,strSysex)
}

edit:
This is my controller I’m wrestling with. As you can see the track name and volume works. But volume wont update from automation sadly.

2

Hi!

You may want to use the callback function on the Host side and not on the Surface Element side.

Try something like this:

hostSelectedTrackChannel.mValue.mVolume.mOnDisplayValueChange = function(activeDevice, objectValue, valueTitle) {
	var strSysex = makeSysex(textAsArray("vl" + objectValue))
    console.log(objectValue)
	console.log("Sysex: " + strSysex)
	midiOutput.sendMidi(activeDevice,strSysex)
}
3

Hi,

Isn’t the SysEx message too expensive to show the value in real time?

And I don’t see a reason to make the custom variable here.

4

It’s not too bad cost wise. I figure I can throttle it a little if it’s too costly. Said device doesn’t receive too much MIDI.

I used a custom variable as my volume control is set up with a custom function I made to handle rounding and midi feedback.
Just keeps it cleaner and neater for me. I’m also not sure I’ll keep an actual volume control or not, but I do want the display to be updated. I use the same variable for both name and volume, but I simplified it here for the actual problem to be highlighted.

5

Thanks for the suggestion, but isn’t this still the same?
I’ll try it later today though when I’m back at my computer. Thanks for the suggestion though.

6

There’s a difference between callbacks invoked on a MR_SurfaceElement or MR_HostValue.

If I understand it correctly, callback on MR_SurfaceElement will be triggered when MIDI is received (ie, you touched the encoder, fader, whatever). Whereas callback on MR_HostValue will be triggered when the host (Cubase/Nuendo) value changes.

And yes, you can send sysex to display values on “real time”. Though you might throttle cubase if trying to send too much info at the same time though.

But I have 24 channels and displays in front of me and it is working pretty well. I use 3 MIDI ports.

2 Likes
7

Oh man, you saved my day!
This worked great. Thank you so much for this insight!

That was kind of logical but also kind of confusing why it didn’t work initially, as the actual value for the volume was being updated from the automated value as expected, just not the display value.
To me I’d still consider this a bug, what do you think?

8

I think it’s an intended behaviour, It’s already been discussed in another thread.

Otherwise i don’t see why there would be 2 different ways for invoking callback. It’s probably to avoid any throttle on the MIDI communication. You can chose which parameters will update on automation and which should update only when touching them.

As I see it, I don’t need to display the volume value on “real time”, especially since i have motorized faders and other ways of feedback. But i might find useful to display that value when I have my finger on the fader. So it makes sense.

Glad I could help.

Thomas

1 Like
9

Makes sense. I just really had no idea, as I just recently got into this, and I reckon I am going a bit faster than I should at times, but it’s a great way to learn by making as many mistakes as possible in a short amount of time.

Thanks again for elaborating further.
I will look into maybe throttling it a little, as I don’t need real time messages, but I do want them up to date, and I don’t think that should be a huge issue.

I marked this as solved with your post as well, and I see the thread was modded a little to change the tags to tips and tricks. Thanks mods!

10

So just adding on here to how I ended up solving this after experimenting a bit.
My controller isn’t the fastest, as it’s just running circuitpython on a 40mhz cpu, it was actually a bit challenging to keep updating the screen at a 25-45fps or so when I sent it over real time with sysex as above. Performance wise from Cubase it is no big deal really, and it’s not too hard to throttle it a bit.

What I actually ended up with though, was just making a midi to ‘volume’ look-up table. So I ended up just making use of the midi cc for my volume control in the end anyway, and I just look up the corresponding volume ‘value’ in a list of 128 values.
It solves what I want with my controller. It’s not accurate if I send automation in finer resolution than midi, but my use case for my controller is more about having an indication of that volume has changed.
So it’s a bit out of scope for what we do with the MIDI Remote API, but I figured I’d add this on as a way to solve it outside the box if a ‘good enough’ value is fine.