More generic remote confusion...

"<flags>1</flags>" = R (receive flag)
"<flags>2</flags>" = T (transmit flag)
"<flags>3</flags>" = R & T (receive and transmit flags)

Out of all the things in Cubase; the way the generic remotes are handled is the most confusing. I’ve had issues before but again I want to truly understand how this works so I can help others in the future etc. I personally have a working setup but my curiosity leads me to trying more and more alternatives in search of the most efficient. Whilst doing so, I discovered there is a difference between these three things when there really shouldn’t be:

XML 1:

<?xml version="1.0" encoding="UTF-8"?>
<remotedescription version="1.1">
<ctrltable name="Standard MIDI">
<ctrl><name>Volume 1R</name><stat>176</stat><chan>0</chan><addr>7</addr><max>127</max><flags>1</flags></ctrl>
<ctrl><name>Volume 1T</name><stat>176</stat><chan>0</chan><addr>7</addr><max>127</max><flags>2</flags></ctrl>
</ctrltable>
<bank name="R + T">
<entry ctrl="Volume 1R">
<value><device>Mixer</device><chan>1</chan><name>volume</name><flags>0</flags></value>
</entry>
<entry ctrl="Volume 1T">
<value><device>Mixer</device><chan>1</chan><name>volume</name><flags>0</flags></value>
</entry>
</bank>
</remotedescription>

Keep in mind that each entry corresponds to the same MIDI track. That is, “Track 1”. Hence the “1”.

XML 2:

<?xml version="1.0" encoding="UTF-8"?>
<remotedescription version="1.1">
<ctrltable name="Standard MIDI">
<ctrl><name>Volume 1RT</name><stat>176</stat><chan>0</chan><addr>7</addr><max>127</max><flags>3</flags></ctrl>
</ctrltable>
<bank name="R & T">
<entry ctrl="Volume 1RT">
<value><device>Mixer</device><chan>1</chan><name>volume</name><flags>0</flags></value>
</entry>
</bank>
</remotedescription>

XML 3:

<?xml version="1.0" encoding="UTF-8"?>
<remotedescription version="1.1">
<ctrltable name="Standard MIDI">
<ctrl><name>Volume 1T</name><stat>176</stat><chan>0</chan><addr>7</addr><max>127</max><flags>2</flags></ctrl>
<ctrl><name>Volume 1R</name><stat>176</stat><chan>0</chan><addr>7</addr><max>127</max><flags>1</flags></ctrl>
</ctrltable>
<bank name="T + R">
<entry ctrl="Volume 1T">
<value><device>Mixer</device><chan>1</chan><name>volume</name><flags>0</flags></value>
</entry>
<entry ctrl="Volume 1R">
<value><device>Mixer</device><chan>1</chan><name>volume</name><flags>0</flags></value>
</entry>
</bank>
</remotedescription>

The first code block WILL transmit (T flag) a MIDI message through the MIDI output (set within Device Setup >> Generic Remote) after having received (R flag) a MIDI message through the MIDI input (set within Device Setup >> Generic Remote).

The second code block WON’T transmit (T flag) a MIDI message through the MIDI output (set within Device Setup >> Generic Remote) after having received (R flag) a MIDI message through the MIDI input (set within Device Setup >> Generic Remote).

The third code block WON’T transmit (T flag) a MIDI message through the MIDI output (set within Device Setup >> Generic Remote) after having NOT received (R flag) a MIDI message through the MIDI input (set within Device Setup >> Generic Remote).

Doesn’t make much sense to me. Literally, we’re talking about a functional difference between:

R
T

,

R & T

and

T
R

Any explanation?

Hi,

How do these two examples look like in the Genereci Remote Device window, please?

I edited the original post! There’s an additional example.

In all 3 examples…
1: I reset my physical controller’s volume fader to 127.
2: I reset the MixConsole’s volume fader to 127.
3: I re-import the corresponding XML file.
4: I click apply.
5: I move my physical controller’s volume fader from 127 down to 70.

XML 1:


XML 2:

XML 3:

I’m wondering if anyone knows the reasoning behind this behavior? I’d like to know for sure what’s going on. Especially since it’s not documented anywhere in the Operation Manual.

(Martin, hope you don’t mind if I jump in here)

I’m sorry, I can’t begin to understand what you’re report is getting at, but as far as what the R and T flags do, I think I can help.

With R and T both on, the message from the controller device gets transmitted to the Generic Remote, and when the corresponding object in Cubase is moved it’s data is sent back to the controller device for the purpose of, e.g., updating its display.

Hi,

@StevenInChicago: Of course, your input is always very welcome.

@thelittlegumnut: It’s common to use it on one “object” only. So you have one line with R+T. Btw, I can see some Input Transformer on your MIDI Track. What does it do?

It’s fine lol. I just like to nitpick with this program. After experimenting with generic remotes for about a month now, I’ve realized just how intricate Cubase’s routing really is. So trying to paint a picture of the issue is pretty tricky.

To keep it simple:

If you look at all of the .JPGs, the generic remote MIDI Output dropdown is set to “monitor” - which is just a virtual MIDI port I created in order to intercept MIDI messages in MIDI-OX. MIDI-OX just allows me to view those messages and optionally redirect them back to my hardware controller.

With R+T.JPG, MIDI-OX is receiving messages from the generic remote MIDI Output when I move my hardware fader. This means that MIDI must be flowing through the generic remote MIDI Output dropdown, because no other MIDI output method has been specified in the track inspector window on the left of the screen.

With R&T.JPG, you would think the same thing would happen right? At least, I thought so. I was wrong, and it turns out that upon moving my hardware fader, no messages are sent through the MIDI Output dropdown. Otherwise, I would see messages inside MIDI-OX.

With T+R.JPG, I thought that it would be the same as R+T.JPG. Apparently not, as this setup doesn’t even receive incoming MIDI in the first place.

I can hypothesize as much as I want about this; Perhaps it’s the order that the conditions come in? For example - If R is before T, then process the incoming MIDI with R first, then T. But at the end of the day, it’s just a guess and I thought I’d check the forum to see if anyone knows for sure what the generic remote routing scheme is.

I attempted to re-explain some more things in my response to Steve, but to answer your question:

In each example I use only 1 MIDI track called “MIDI 01”. This MIDI track has the Input Transformer set to Local, and contains 2 modules. The first Module is just a basic channel filter. It will filter out any incoming MIDI that isn’t equal to channel 1. The second Module is also a filter, but this filter will filter out any incoming MIDI CC 7 (Main Volume) messages and any MIDI CC 10 (Pan) messages.

Module 1:


Module 2:

Hope you are having fun! It’s just simple in and out messaging between the app and the device.

You’re making me question why I’m doing this… :ugeek: lol I admit it’s pretty stupid that I care so much about this, but I just want to see it documented. Actually, I guess it’s because initially - due to lack of documentation on such intricacies - this caused me to spend days figuring out a solution to my routing. I eventually found a workaround to my issue using MixConsole channel linking but I’m kind of hoping some Steinberg engineer will explain the internals in fine enough detail. As it turns out, the channel linking wasn’t necessary if I had of just used the R+T method. Before the channel linking, I was using the R&T method. Understandably… I was curious as to why on earth R+T worked but R&T didn’t.

Hi,

I just tested it. I didn’t use any Input Transformer filters and the result is what I expect.

  • Main scenario (R,T on the same line)
    – works as a bidirectional communication.

  • 2nd scenario (R in the 1st line, T in the 2nd line) (look at it from the developer point of view)
    – Receiving data: Cubase loops over the array of all lines in the Generic Remote. In the 1st line, it finds a match. MIDI CC7 is received, so it’s used for the linked MIDI Track. The code get out of the loop to don’t run unnecessary code (to check all other lines of the Generic Remote). It doesn’t make sense to test them, because you can set all flags on the 1st line at once.
    – Transmitting data: Cubase loops over all lines, which are flagged by Transmit (it doesn’t make sense, and it costs time and power, to loop over other flags). Cubase finds a match, on the 2nd line, and transmit the data.

  • 3rd scenario (T in the 1st line, R in the 2nd line) (look at it from the developer point of view)
    – Receiving data: Cubase loops over the array of all lines in the Generic Remote. In the 1st line, it finds a match. There is no Receive flag, so Cubase doesn’t send the data forward. Same as it is explained above, the code get out of the loop to don’t run unnecessary code (to check all other lines of the Generic Remote). It doesn’t make sense to test them, because you can set all flags on the 1st line at once.
    – Transmitting data: Cubase loops over all lines, which are flagged by Transmit (it doesn’t make sense, and it costs time and power, to loop over other flags). Cubase finds a match, on the 1st line, and transmit the data.

So all scenarios are supported (you can set all combinations of flags on one line), and also power and time is saved.

I don’t know the code, this is just my expected restoration from the behavior I observed.

I mostly agree with what you’re saying. But there’s a crucial difference between the above two scenarios: If you don’t use the mouse at all, and only use the hardware fader, then only the second scenario will transmit data. In Scenario 1 (R&T.JPG), there is no transmission using only the hardware fader. In Scenario 2 (R+T.JPG), transmission appears to work when the MixConsole is changed by the hardware fader (via R flag). It’s weird.

What you’re saying makes a lot of sense. I wish there was a way we could know for sure. Thanks for the response! I appreciate your patience!

Do you mean to transmit the same data, which are receiving by Cubase?

Cubase transmits the data only if you move the controller from Cubase to prevent MIDI loopback feedback. Why would you send the data back to the source?

Yes.

The reason I’m doing it is a little complicated and has to do with my hardware having a fader pickup mode that I can’t turn off. If I don’t send the messages back to my hardware, then my hardware fader will not pickup from where the corresponding MixConsole fader left off.

The loopback doesn’t occur because my hardware doesn’t “thru” or repeat incoming MIDI at any point. It’s funny, but Scenario 2 (R+T.JPG) actually accomplishes what I want. It’s just that I was confused as to why it does, and wasn’t satisfied with the lack of documentation on generic remote conditions. After all, I spent days figuring out something that really should have been in the manual. The manual only contains basic information as to how the flags work. If it had an explanation somewhat similar to yours, that would have sufficed. If there’s a way to deduce the underlying mechanics of generic remotes through testing, I would really like to know! Otherwise, I might have to formulate a request to Steinberg asking for the manual be updated; to include further information on generic remote flags and order of conditions. I can always link to this forum post.