OpenGL Renderer not working as expected in Ableton Live 10 (Edit: Also Cubase 10.5)

We have distorted graphics when loading our plugin in Live 10. All other hosts we tried look more or less okay. We tracked that down to using the OpenGL Renderer.

It can easily be reproduced with the skeleton Audio Plugin project and attaching an OpenGL context. See attached project files.

I attached two screenshots showing the problem. Live 10 offers an option to “Autoscale” a plugin and it does look different depending on Autoscale being enabled or not but both are distorted.

Live10-OpenGL-WithAutoscale
Live10-OpenGL-NoAutoscale
TestOpenGL.zip (5.1 KB)

1 Like

As a quick update: This is also true if one activates “HiDPI” mode in Cubase 10.5. It looks like the second screenshot and not crisp and centered as expected.

So I found one of the two (at least) bugs that make the OpenGL renderer not work correctly in Ableton Live:

Live 10 and propably some other hosts support a VST2 extension by PreSonus called “ViewDpiScaling”. It works by the host querying for the “supportsViewDpiScaling” capability and if so by sending a “kEffEditSetContentScaleFactor” message to the plugin.

The JUCE VST2 wrapper reports this capability however it does not handle the incoming message correctly. JUCE treats it as an “effVendorSpecific”-opcode and checks the payload for the “kEffEditSetContentScaleFactor” identifier.

However the “kEffEditSetContentScaleFactor” is already an opcode (‘AeCs’) in itself which is not handled by the wrapper.

I put in this piece of code inside JuceVSTWrapper::dispatcher() to handle the opcode:

	if ( opCode == JUCE_MULTICHAR_CONSTANT ( 'A', 'e', 'C', 's' )
		 && args.index == JUCE_MULTICHAR_CONSTANT ( 'P', 'r', 'e', 'S' ) )
	{
		return handleSetContentScaleFactor ( args.opt );
	}

With this in place the OpenGL renderer works fine as long as “Autoscale Plugin” is turned off.

The API C++ headers can be found on the PreSonus website for further reference.

4 Likes

If that’s the case, then it looks more like a Live bug. If you open a VST2 plug-in in Presonus Studio One on a hiDPI machine, the view DPI scaling extension is sent with an opcode of 50 (effVendorSpecific), the vendor ID ‘PreS’ is sent as the index and the ‘AeCs’ opcode is sent as the value. I would assume that Studio One is the reference host for this kind of thing as the extensions are theirs.

True. I don’t have Studio One at hand so I could not check that. It would still make sense to include this work-around for Live 10.

I am also still struggling to get OpenGL to render at the correct position/size with “Autoscale” turned on. I modified the context creation somewhat to get an OpenGL 3.2 context which then allows me to connect via RenderDoc and examine the OpenGL calls.

It looks like the texture that is generated for the top level component is crisp but too small. The plugin “thinks” it should render an image of size 1222x920 but the physical size of the window is 1527x1150.

The final step of drawing the texture onto the backbuffer also seems to be unaware of the physical size of the backbuffer and draws the texture into the lower left corner leaving a black border at the top and at the right.

When examining the backbuffer in RenderDoc it is still crisp but for whatever reason it looks distorted when finally seen in the plugin window in Live 10.

I tried fiddling with the parameters passed to the shader in OpenGLContext::copyTexture() but did not get any useful result.

This is driving me crazy!

1 Like

Also: Cubase 10.5 with HiDpi

This time the texture has the same size 1376x1036 as the physical window but the backbuffer is just 1160x828. So the texture gets cut off when being copied into the backbuffer.

When finally visible in the plugin window the backbuffer is then stretched to fit. However the visible image is not blurry as one would expect but also strangely distorted, similar to what it looks like in Live 10.

Not happy with the current state. Fact is, wherever it’s Ableton, Cubase or other major hosts, there are at least a few cases where it still fails. Either the scaling is off by a factor, resulting in blurry images. Or the frame buffer is cut off.

Seems to be an ongoing issue. Could it be a fundamentally wrong approach? If we fix this problem, what host will break after that? The Software renderer works. It’s not impossible, or is it?

Can we at least get a safety measure, sanity checks and what not, so it automatically adjusts in case of a mismatch? Not purely depending on a dpi or scale factor that is obviously reported wrong in some cases.

2 Likes

Unhappy is actually quite an understatement. It is just a window we want the rendering to happen at native resolution.

I’m having the same issues here with Cubase 10.5 and Live 10 and OpenGL (VST3/VST2) :unamused:
The thing is that I’m not using Juce, and everything works fine with those hosts on Windows

  • Studio One 4.6
  • Bitwig Studio 3.1
  • FL Studio 20.6
  • Reaper 6.0.4 beta
  • Tracktion Waveform 10

I’ve also checked some Arturia and NI plug-ins which exhibit the same problems on C10, running fine elsewhere.
So it’s definitely looks like a bug on the host side.

I got a response from one of the devs over at the vst3 sdk forum who told me he forwarded the issue back to the Cubase dev team. Let’s hope they’ll sort it this out asap.