Generic Remote - transmit and pickup flags difference?

This is more of a why question than a how, because I already have a working configuration. Though… I am worried I might be sending duplicate MIDI CC messages somewhere.

I really need to know the difference between the transmit and pickup flags in the Generic Remote configuration. They appear to do the exact same thing for me.

Here’s an attempt at a simplified flowchart explaining my routing:

  • = MIDI send

physical fader channel 1 -->
…generic remote config -->
…mixconsole HALion Sonic SE volume channel 1 -->
…* HALion Sonic SE volume channel 1
…* external seq mixer volume channel 1

In this setup, the transmit and pickup flags (T and P) do the same thing. Or do they? I have a feeling that transmit is sending an ADDITIONAL duplicate of the incoming MIDI CC from my physical fader.


The Operation Manual explains it pretty good:
Transmit – activate this if a MIDI message should be transmitted when the corresponding value in the program changes.

Often, the parameter settings of your Quick Controls (or other remotely controlled parameters) are initially different from the settings of your hardware controls, for example, when the hardware controls control different Quick Controls on different tracks. In this case, you will notice that moving a hardware control changes the previous value of a parameter in a way that it is initially set to the zero position, before it is changed. Thus, you always lose your previous setting of the parameter. To avoid this, you can activate Pick-up Mode. This has the effect that when you move your hardware control, you can only change the parameter once the control reaches the parameter’s previous value. The control “picks up” the parameter at the value to which it was last set.

I felt like messing around with it for a bit today, and noticed that it does come in handy in very specific circumstances. Just to clarify though for anyone else that may be confused by this definition…

“corresponding value in the program changes”:

If I have my generic remote set to control a MIDI track’s volume, does this mean that an additional MIDI message will be transmitted explicitly each time the volume value changes? Like from 100 to 101? Or does this mean that a MIDI message will be transmitted each time someone changes the “program”; the generic remote configuration or mixconsole configuration. This difference really matters. If someone already has a MIDI output/transmit CHANNEL configured on their MIDI track (plus MIDI-thru in preferences), then sending duplicate messages could screw things up. However, if that isn’t the case, and it only sends messages upon changing the mixconsole or generic remote itself, then it’s very beneficial and handy for me to use.

To put it simply… What does “value in the program changes” mean? What does it mean by program? Cubase itself? The particular instrument “program”? Also, what is value? The MIDI value? Or the configuration?


I think, I copied this text from the part about the Program Change. But it works the same for other parameters like Volume, Pan, Quick Controls, etc., etc.

So it always transmit the value if you change it. The one, you defined in the Generic Remote Device.

I downloaded MIDI-OX and loopMIDI to check for duplicate messages and as it turns out… there is some duplicates being sent for an unknown reason. I traced the problem down to it’s basic roots but I can’t figure out where the additional 2 messages are coming from. I’ve attached some images. Could it be a bug?

Just so you know, I have NO additional settings other than those in the inspector.jpg image i attached above. I cleared my Generic Remote setup and even turned off MIDI thru. I can’t understand the additional messages and where they are coming from.

What is MIDI Port PC Out? What is the Incomming MIDI Port to the MIDI OX?

“PC out” is just the name that I gave to my virtual MIDI port in the loopMIDI software. I called it that because I wanted to check for MIDI messages leaving Cubase. In other words; out of my PC. loopMIDI’s PC out port is simply acting as a bridge for MIDI messages to go from Cubase into MIDI-OX. As you can see, I simply use loopMIDI and MIDI-OX to capture the outgoing MIDI messages:

MIDI keyboard >> Steinberg UR22 >> Cubase >> PC out (loopMIDI virtual port, selected from inside the inspector) >> MIDI-OX >> Nothing

MIDI-OX is detecting additional pointless MIDI messages. I can confirm that MIDI-OX isn’t displaying multiple devices’ MIDI messages in the screenshots I took above, and that the only MIDI port that is being monitored is the “PC out” loopMIDI virtual port.

There is a workaround that I know, but it limits me tremendously in other areas of the MIDI flow of data:

  1. In the inspector, set the MIDI track’s MIDI input routing to Steinberg UR22, and set the MIDI output routing to “not connected”.
  2. Open the generic remote tab within the Device Setup window and set the MIDI input to Steinberg UR22, and set the MIDI output to PC out.
  3. Set up a Generic Remote condition (upper panel) to handle incoming CC 7 (Main Volume) and activate the R (Receive) and T (Transmit) flags.
  4. Set up the corresponding action (lower panel) to control the Volume of the said MIDI track within the “Mixer” (MixConsole).

For some reason, if you perform the exact same operations I did before in the above screenshots, you will now get a reasonable result within MIDI-OX. Just a single CC 7 (Main Volume) 101 message. The downside, is that the physical controllers on my MIDI keyboard won’t leave Cubase at any point. They will move the faders on the MixConsole, sure. But no CC 7 messages will leave Cubase, which is what I’d like. Apparently, the T (Transmit) flag doesn’t account for visible (!) “program changes” if those program changes were caused by an external force. As opposed to manually clicking and moving the faders within the MixConsole, which will indeed send MIDI CC 7 messages out of Cubase via loopMIDI’s PC out.

I can kind of understand the T flag’s function; It’s actions pertain to the MixConsole (or some other internal controller) being clicked (and dragged, or scrolled), or being reset (switched-to and switched-from). However, if the message is also being received with the R flag, then no transmission of the message will be sent. So I have a choice, either deal with multiple messages, or sacrifice my physical controller usage.

This is why I’m stuck figuring out this issue with multiple messages. If it were solved, I wouldn’t have to figure any of this out. Not sure if it’s a bug or if there’s something about the Cubase architecture that I don’t understand…

But if there’s no decent reason behind this, then I may submit a bug report because it literally makes no sense why there are multiple messages being sent and it’s detrimental to the use of the product.


I just tested it, and then, when I got the results, I realized, I did it once before already. So, the result is:

  • There is alway 1 unit less in Cubase, then it is on the HW device, if you control Volume parameter (it’s visible especially if you control the Volume of the MIDI track). So if the HW device set 100, there is 99 in Cubase. The reason for this is, the Volume interprets 0 as Off, not as 0.
  • 0(HW) = Off(Cubase)
  • 1(HW) = 0(Cubase)
  • 126(HW) = 125(Cubase)
  • 127(HW) = 127(Cubase)
  • It doesn’t matter if you Receive and Transmit the value, or if you Receive it. Always 1 unit less.

Enable Pick-up mode flag doesn’t send the data out. Enable Transmit mode flag does send the data out. So there is no duplicate with these two parameters.

  • Transmit sends the data out, if you move the controller in Cubase.
  • Pick-up mode takes care, if you change the value in Cubase and the fader on the HW doesn’t move (because it’s not motorized), Cubase will receive the data from HW only, if the value from HW is close to the value, which is in Cubase. This prevents jumps, if you don’t use motorized controller.
  • Both work as expected.

I’d just like to add the reason for the apparent “unnecessary” MIDI CC 7 (Main Volume) messages in case someone happens to stumble across this. It would be nice to get some feedback as well just in case I’ve messed something up.

A few days ago I realized that the additional messages have nothing to do with Generic Remote routing nor MIDI routing. They are also more likely generated by-design on Steinberg’s part as opposed to being a bug. Having said that, these can be reasonably considered duplicate MIDI messages.

Before reading this, I’d just like to note that Martin is right in the message above. You should read through that first to clear up some extra confusion. I’m also presuming that MIDI thru is enabled in preferences, and also presuming that filtering MIDI by channel is enabled using the Input Transformer within the Track Inspector.

For starters, it’s actually the MixConsole’s implementation. So if you use Generic Remote conditions to filter messages through to the Mixer (MixConsole) in the Device Setup, you will always notice additional messages generated when the corresponding value shifts. You will also notice additional messages if you use your mouse to change the MixConsole’s parameters in real-time. For example, whenever a MixConsole’s value is changed, the MixConsole generates a MIDI CC message pertaining to the parameter’s current value before it is changed. The MixConsole also generates a message pertaining to the parameter’s final value after it is changed. A good analogy would be to imagine the MixConsole as though it is a real-life hardware mixer. In the Cubase MixConsole’s case; the moment your hand touches the controller, a MIDI CC is sent that corresponds to the controllers position before your hand has moved. Then, as you slide (or turn, etc) the controller, the values you sweep over all get sent a single time. Lastly, as you finish your movement and lift your hand off the controller, a final MIDI CC is sent that corresponds to the controllers position your hand has let go. In this analogy, replace your hand with your left mouse button. Instead of touching, sliding and letting go: click, drag and release.

If you are controlling the MixConsole via a Generic Remote setup, then you will notice the same effect when you use your physical controller. Because Cubase can’t figure out when you place your hand on the physical controller, it waits until you first move the fader or knob. This can produce an annoying “unnecessary” MIDI message. It seems to be unnecessary because chances are, your MixConsole’s parameter was already set to that before movement occurred, and you only wanted the “sweeping” values to be sent. Cubase also has no way of knowing when you let go of the physical controller, so it waits a certain period of time before sending the “release” message. This will also produce an equally as annoying “unnecessary” MIDI message. Just to make sure you aren’t moving the fader or knob extremely slowly. By default, this period appears to be around 1 second.

The above behavior is pretty confusing and I’m not sure if it’s in the manual or not. The important thing to note, is that it occurs when using mapped physical controllers through the Generic Remote interface, as well as when using the mouse within the DAW itself. Either way, hopefully it’ll save someone a day of boring debugging. So I’m documenting it.

I only know of one configuration that can act as a possible workaround. It involves using the T (Transmit) flag from within the Generic Remote setup screen. If you enable the T flag for a controller in the top panel that corresponds to a parameter on the MixConsole in the bottom panel, then the MixConsole will transmit the control change message given in the top panel to whatever device is selected in the MIDI Output dropdown above both panels, as well as whatever device is selected in the Output Routing dropdown in the Track Inspector. The key, is that the T flag will only make the MixConsole transmit MIDI data when it is visibly changed. That is, when the value itself changes within the program. Unfortunately, the T flag won’t stop messages already flowing to the Output Routing device set in the Track Inspector. Enabling the T flag without doing anything else will make even more “unnecessary” duplicates. But, if you set the Output Routing to Not Connected, then this issue is technically resolved. However, it’s pretty limiting, because it forces you to use Generic Remote conditions for everything. Even Note On/Off messages. What you can do to get your other MIDI messages back without duplicates, is set up a MIDI send track with the Transformer MIDI plugin set. Within the transformer, you can delete the MIDI messages that directly from the MixConsole to the Output Routing dropdown whilst still transmitting those MIDI messages with the T flag through the MIDI Output dropdown within the Generic Remote setup.

Wrap your head around that. Of course, that’s if you must remove those “start” and “end” MIDI messages from the MixConsole at all costs. You could just choose to live with it knowing that they’re easily manually deleted from within the list editor or project browser.