Artifacting in one channel only VST3 OpenGL

Hello all,

Working on a plugin with OpenGL and trying to setup some basic interaction between 3D rotation and delay time.

My delay matrix achieves the pitch shifting I’m after when the object rotates but, tends to create artifacts in only the right channel. The interpolation I’m using seems to be perfect only on the left channel. Though, I’m using the same interpolation algorithm for each channel so I’m a little lost.

My DSP seems completely secure. Both channels are processed exactly the same and are initialized properly every time the dsp is called. I’ve noticed that when I load the plugin as a AU in Ableton the artifacting goes away. However, the signal becomes mono. I’ve exhausted every single resource I have access to and have tried nearly every solution I could think of.

Has anyone else ran into a similar problem? Is it possibly a quirk that exists because of the OpenGL interface I’m using?

super lost…

-Jake

I “solved” it. If you load a .obj 3D model with more than ~2000-4000 (rough estimate) it somehow affects the audio thread. Weird but, whatever, I will use a lower poly model.

This sounds like there might be some kind of synchronisation problem between the OpenGL renderer and the audio thread. How are you reporting rotation values from the renderer to your DSP?

I was handling it via lambda function inside my AudioProcessorEditor
gl = std::make_unique<OpenGLOut>();
gl->update_callback = [&](float val){p.update_dt(std::abs(val));};

then inside my renderOpenGL() function

if(update_callback)

            update_callback(std::abs(sum_rotation()));

sorry for the excessive std::abs() I was losing my mind a little.

after switching to an object with less vertices I found these lambda functions work perfectly.

Depending on what p.update_dt does, this could well cause problems. renderOpenGL is called on a special renderer thread, which is different to the audio callback thread. If update_dt writes to a variable at the same time as the audio thread reads from that variable, this will trigger a data race, which is undefined behaviour. Common ways to guard against data races are to use atomics, mutexes, or wait-free-queues.