(Remote Control Editor) with Plugin Alliance has serious issues

Everything in C12 was working perfectly and I was happy with it, except the MIDI Remote Learn Function with Plugin Alliance plugins !!!

The most desired need for any mix engineer is to control the SSL channel Strip with a controller surface (more than 8 parameters), which couldn’t happen with C12+PA, I’ve reached out to PA and they told me that this issue is related to Steinberg. I hoped this issue would be addressed in C13 but it got worse, the whole Midi Remote Mapping basic functions have been removed from C13 and I’m desperately waiting for the updates.

Screen Shots of the issue

Here’s the Remote Control Editor:

Whenever I want to assign a parameter it won’t do anything
ex. changing (power) to (Virtual gain)

the parameter still shows (Power)

also the LEARN Function doesn’t work either

any help on this ?

Hi, here it works as expected for many plugins I’ve just checked. However, I don’t have Plugin Alliance plugins. Do this thing happen only with these plugins or with other as well?

Yeah I know, it works properly on UAD, Waves, Oeksound, Soundradix, and many other 3rd party plugins, but it doesn’t work with some of them such as PluginAlliance & iZotope, I’ve reached out to them and they told me to ask Steinberg for the related issue.

Ah, indeed, I see it too now, to iZotope plugins. In fact I’ve check them in CB11 up to CB13, no way to “unlock” them. It’s difficult to understand who’s in fault here. Since many plugins do work as expected, and since this problem is also there in CB11 I somehow think that there’s something missed in the implementations of the non-working plugins. On the other hand, there indeed may be something missed by Steinberg, who knows… Maybe you should open a support ticket to Steinberg?


Maybe… It is hilarious how stuff like this, is treated by Steinberg staff. Why? Because most of the time, a user will experience ping-pong between the two companies. Moreover it would have way more weight if Steinberg would report a issue / open a support ticket, because it is sadly common that user reports often are not trusted enough, i.e. “Problem Exists Between Keyboard And Chair”, “DAU” etc.

One example i experienced is, that the drivers of my Logitech keyboard lead to my Midi-interface not working properly. I did report that at Logitech, but nothing happened to solve the problem, until i went to MOTU and explained my problem there and begged them to report the issue at Logitech. Guess what happened? In less of a week the problem was gone.

It is a shame, that problems like these, has to be solved by users IMHO. It should be the opposite, as it is in the interest of both companies to solve the problem and this should not be done on the back of the users, that paid both companies to have something that was promised to work.

1 Like

I absolutely agree. This is why I suggested a ticket to Steinberg, perhaps they could test and if the problem is not on the VST3 side, they could urge the devs of these plugins to make corrections. If, on the other hand, it’s an intrinsic problem at Steinberg’s side, again, they could most probably resolve it.

1 Like

I would put my expectations very low on this, but who knows…

I think it is better, to collect a list of non working/ not properly working plug-ins and then open a ticket. You already have two examples here and i guess there are more. The more is collected, the more Steinberg is forced into actions from their side.

Also it is better to change the name of the thread or to create a new one. It will create more interest to us users finding more plug-ins. The current name of the thread is to specific to create attention.

1 Like


I’m sorry, you have this experience elsewhere. My experience with Steinberg is the opposite. They take care and deal even with issues of the other companies.

I don’t see it this way. From my point of view, the issue should go from bottom to top, not the other way around. Because as the user, you never know, where the “top” is. Is it the issue of the plug-in, the host (Cubase), the standard (VST), the operating system, the hardware, …? As a user, you have no chance to find the top and it doesn’t make sense to report it somewhere in the middle of the way.

So as a user, if you find an issue with a specific plug-in (moreover if you find out, another plug-in works as expected); report it to the plug-in vendor. If they find out, that the issue is not on their side but on the host (Cubase), they should inform the host vendor. If the host vendor finds out, that the issue is on the standard side, they will inform the standard vendor.


My suggestion was based on this:

1 Like


Then go for it!

1 Like

I dont care what your experience is, simply by the fact that you are either a highly biased person to Steinberg, payed by Steinberg or a fanboy… or all of it.

It has been proofed already that there are at least two plug-ins not working properly in a special environment of the DAW and they work properly elsewise with the DAW. Again, you dont read carefully enough, what is already known.

From now on, i will simply ignore any of your statements. You are Red Flagged.

And what did he here??? He reported it. Dont know what you want. How about you notice that in your black book and you open the ticket???