vstplugins and multprocessing glitching

[Animus]

Some interesting discussion on this thread: http://forum.cubase.net/phpbb2/viewtopic.php?t=109055&postdays=0&postorder=asc&start=25




IMPORTANT NOTICE......READ IN...

FYI.

Since Version 4.x of Cubase, the software has used a wrapper for all plugins that are NON VST3.

It is safe to say, that ONLY VST 3 plugins included with Cubase 4 are geniunely Multicore / CPU / Multiprocessing Compatible.

The buffer settings are actually immaterial as the audio problems are still there just less audible! Do real time mixdowns with MP off and MP on and use phase cancellation to compare the results. Then you will hear the glitches!

Quite often the engine will not break down and the audio will be processed perfectly. However, due to this issue, some combinations of plugins may cause the audio engine to glitch. And some single instances of plugins will do the same. For instance some NI plugins alone function perfectly but in use with UAD plugins especially or other PDC inducing plugins the engine will glitch when MP is used.

CPU spikes are related to this issue. And have also been apparent with some UAD-1 plugins in combination when those plugins are used in groups.

These two issues are somehow related. So much that will an otherwise perfect Quad Core system with first class specs, I no longer use MP throughout.

I certainly DO also turn MP off for final mixdown. I have not yet noticed glitches induced in recorded audio.

Basically put there is something wrong with the VST wrapper or the way the program uses it. It causes these spikes and glitches. And even if UAD fix their end, there will still be combinations of plugins that are able to break the MP audio engine in Cubase because of this....

TAKE CARE! :-)

and ...have fun :-)



I haven't read the whole thread, only the statement of Jake68, so take what's following for what it is.

When performing a phase cancellation test with a project that includes plugins (of any kind) you will see spikes and glitches.
That has been documented since Nuendo1 and it's no secret at all. I have talked about that before on Nuendo.com.
The spike or glitch is caused by the buffering of plugins and is unpredictable.
In short it comes down to this: (And I am cutting some corners here - I am no specialist either ...)

Whenever a plugin sees audio coming (lookahead function), the plugin buffers the audio in advance so that the process can keep up with "real time".
The conditions in which spikes are generated is when registers are full, need to be cleared or switched, and more of that kind.
So it's unpredictable, except for that fact that it is guaranteed that it will happen.
Note that this is not audible when there is audio present, the spikes can indeed be huge, but they are unnoticeable to the ear.

In addition to that, there is the issue of multiprocessing. This add the problem that the OS can "switch" a process form one processor to another processor at any time, regardless of the instructions the Host (Cubase) has givin. When a process is switched from one processor to another, this also involves buffering with the described results.
VST3 has anticipated to these problems, and has -for example- separated the GUI processing from the actual processing. This new architecture makes that VST3 plugins will show much less problems than a VST2 plugin, and with the coming of more multiprocessors, the gap will become wider.
Of course, it also depends on the initial design of the VST2 plugin. I am not saying that a very good designed VST2 plugin can't minimize the problems.

Hope This Helps.
Fredo

[LEX]

Nice, so it continues to get worse.

No doubt SEQ5 will just add more to the problems to the point of no return.

How many decades is it going to take before the program actually works?

LEX

[Animus]

Fredo explained more and it sounds like a non-issue if it's the same problem Jake is referring too. Basically there are just inconsistencies in plugin buffering that can cause minute delays in certain areas of the exported audio. When two exported files are exported and phase canceld these shifts will spike, so the "spikes" are not really present in each track alone. If that makes sense.

It is interesting Fredo says this is well documented and not a secret. This is the first I have ever heard of it.

[TAFKAT]

Fredo's answer is an obvious cut and paste from someone a lot closer to the bone .. , and it could easily be read to be refering to the phase cancellation aspect of Jakes explanation.

Either way,

What it doesn't explain is this, why are VST2 plugins that did not cause these 'unpredictable" spikes in Seq3 , start to display this behaviour in Seq4, and as I have witnessed with my benching sessions which have a controlled set of variables, the spiking is definitely worse in later revisions of Cubendo V4.x

Stacy that screenie I sent you was s perfect example with the overload light clipping, but not causing an audible issue in that instance, but I have seen instances where it will cause a glitch a 60% CPU loads, mind you , that behaviour is also dependent on numerous other variables. i.e .the ASIO driver / O.S being employed.

Jakes assertion that its being caused by some form of added arbitration has been debated quite extensively by myself and a few other knowledgeable types way before he got on the boil, the only difference is that I never claimed it to be a "wrapper" , well not on public anyway . From my understanding all VST2 plugins are hosted within a respective bridge that itself is Native VST3 , so for all intensive purposes , I regarded that as a wrapper - with a spin and polish :-)

The technical wording may not be exactly correct, as I am not a programmer, but you get the jist.

I bet Jake is raising hell on the BETA List with this one, we all know what he was like when he got on a roll with a pet peave- i.e. most will remember the crusade over the Low Res Waveform Bug.. LOL

I have no doubt that VST3 definitely will behave better in such circumstances, it is at least native , problem being that 99% of 3rd party plugins are not VST3, and a lot of developers have basically told Steinberg to take a walk, no other application has implemented VST3 to my understanding, so for most its a Deadendo except for Cubendo, and I can't see the situation changing in the short term. Of course that has nothing to with Steinberg not officially releasing the SDK until 12 months after C4.

There is a thread over at KVR with some plugin developers and Steini developers battling it out over VST3 , I don't have the link handy atm, but it should be easy enough to find..


It is interesting Fredo says this is well documented and not a secret. This is the first I have ever heard of it.

You probably needed to be well versed in Diagonalese or Fredonese to have interpreted it correctly.. :-)

Quick edit : - just read the rest of the thread at C.net, and that the cut and paste was directly from Charlie, still doesn't explain the increased instances in seq4 over seq 3 and earlier, also the assertions that it was widely witnessed in earlier versions is not true to the same extent. To say that it is simply a "surgical / technological" exposure, and that it does not result in an audible click is simply spin , when in fact there are instances where these spikes result in an audio clicks, and it also is capable of neutering the scaling capability of the system quite dramatically.

Also the assertion that all applications will suffer from this behaviour , doesn't seem to hold any water for the earlier poster who ran up the same plugs in Reaper, and did not witness the same behaviour, as well as massively increased scalability.

I have a few questions to the official Steinberg representatives if they are reading in, why is it that the developers cannot communicate directly , instead needing to funnel the information thru the filter, and my second question would be, what is Fredo doing over at Cubase.net in that role , when you have other Administrators and Moderators in place, unless of course on the new combined forums, he will be overseeing both areas , and this is a form of blooding the members to his presence.. ?

[psvennevig]

I'm not entirely sure.

Cubendo is know for being one of the best when it comes to timing and sample accuracy.
If these tests from Jake is to be proven it has to at least be done in another DAW as well. For example Samplitude/Sequoia know for being dead on..

I think the main problem here is the VST plugins used. It was allowed in VST2 (and VST1) to not sync each state of the plugin, this could be used for creative LFO design etc. This was for instance never allowed in DX plugins.
VST2.4 changed all this, and Steinberg made it much more strict how you could develop VST plugins. Around 80% of the plugs out there are still VST2.3, many are VST 2.4 and only 10-20 are VST3 (not counting SB own VST3).

There is LOADS of bad VST code around.

Steinberg needed to change this, and it changed with VST3.
I know the thread at KVR, typical forum thread :-)
At least devs. from Algorithmix (responsible for close to 40% of the DSP code used in commercial plugins) states that VST3 was the rescue of VST code. Also VirSyn and some others speak very highly of VST3.
Devs. also making AU plugins says that the turn to VST3 was easy, because AU plugs had enforced the same kind of regime for years.

We can joke at Steinberg expense all we want. But they still have some of the smartest and best devs. out there. Devs. from Steinberg have made sure that lots of smart technologies are out there.
To say it again, the problem is that the never finish a DAW software :-)

Using only proven VST2.x plugins I can find no, absolutely no difference in nulling tests between N3, N4 and Magix Sequoia.
As Fredo says in the thread, small variances when doing automation, pan, routing etc, can occur with a lot of plugins, just because it was allowed in earlier VST spec.

As of Seq4 (Cubendo 4) using a VST3 to VST2.x bridge I do not know.
Cubendo 4.1 changed the audio engine quite much. The VST2.x code is as I've been explained by a Dev. still the same except for the spec. being followed more tightly, this rendering a lot of older VST plugs on usable.
And the VST2.x support is in a separate module, but this is just a new way of developing, its a separate module that can be patched without updating the .exe file. Earlier it was built into the .exe itself.

What WOULD be nice is if one of the devs. could step in and actually explain this in detail.
If we didn't understand a thing wouldn't matter, just stepping in would be the great improvement.


With respect,
Pål

[LEX]

I'm not entirely sure.

Cubendo is know for being one of the best when it comes to timing and sample accuracy.
If these tests from Jake is to be proven it has to at least be done in another DAW as well. For example Samplitude/Sequoia know for being dead on..

I think the main problem here is the VST plugins used. It was allowed in VST2 (and VST1) to not sync each state of the plugin, this could be used for creative LFO design etc. This was for instance never allowed in DX plugins.
VST2.4 changed all this, and Steinberg made it much more strict how you could develop VST plugins. Around 80% of the plugs out there are still VST2.3, many are VST 2.4 and only 10-20 are VST3 (not counting SB own VST3).

There is LOADS of bad VST code around.

Steinberg needed to change this, and it changed with VST3.
I know the thread at KVR, typical forum thread :-)
At least devs. from Algorithmix (responsible for close to 40% of the DSP code used in commercial plugins) states that VST3 was the rescue of VST code. Also VirSyn and some others speak very highly of VST3.
Devs. also making AU plugins says that the turn to VST3 was easy, because AU plugs had enforced the same kind of regime for years.

We can joke at Steinberg expense all we want. But they still have some of the smartest and best devs. out there. Devs. from Steinberg have made sure that lots of smart technologies are out there.
To say it again, the problem is that the never finish a DAW software :-)

Using only proven VST2.x plugins I can find no, absolutely no difference in nulling tests between N3, N4 and Magix Sequoia.
As Fredo says in the thread, small variances when doing automation, pan, routing etc, can occur with a lot of plugins, just because it was allowed in earlier VST spec.

As of Seq4 (Cubendo 4) using a VST3 to VST2.x bridge I do not know.
Cubendo 4.1 changed the audio engine quite much. The VST2.x code is as I've been explained by a Dev. still the same except for the spec. being followed more tightly, this rendering a lot of older VST plugs on usable.
And the VST2.x support is in a separate module, but this is just a new way of developing, its a separate module that can be patched without updating the .exe file. Earlier it was built into the .exe itself.

What WOULD be nice is if one of the devs. could step in and actually explain this in detail.
If we didn't understand a thing wouldn't matter, just stepping in would be the great improvement.


With respect,
Pål

Can users get a list of "proven" plugins?

Basically, I'd say 99 percent of the users out there are completely unaware of this and there is no list of what is problematic or not.

LEX

[TAFKAT]

And the VST2.x support is in a separate module, but this is just a new way of developing, its a separate module that can be patched without updating the .exe file. Earlier it was built into the .exe itself.


Hey Pål,

Isn't a separate module another way of describing what I posted earlier in regards to the added arbitration.., notice I didn't say "Wrapper".. :-)

[psvennevig]

Hey Pål,

Isn't a separate module another way of describing what I posted earlier in regards to the added arbitration.., notice I didn't say "Wrapper".. :-)

Maybe, I do not know.
From the way it was explained to me I understood it was the same as earlier.
It is a common way to do development these days to break down the app in modules. This way modules can be used in other version of the APP without recompiling etc. etc.

If we call it a wrapper, a plugin, module whatever. Only the devs. can explain it.

P

[Animus]

It sounds like it is two different issues if I am understanding it correctly then. An issue when it actually glitches the audio playback and the issue Fredo is describing where it is just glitches in phase cancelled audio but not actual glitches in sources.

[psvennevig]

Can users get a list of "proven" plugins?

Basically, I'd say 99 percent of the users out there are completely unaware of this and there is no list of what is problematic or not.

LEX

By proven I just meant tried and true.
Like: Waves Q10, URS Channel Strip PRO, Sony Oxford EQ/Dynamics etc. etc.
And Steinberg VST2.x plugins.
And Algorithmix Orange/RED eq.

Pål

[TAFKAT]

Maybe, I do not know.
From the way it was explained to me I understood it was the same as earlier.
It is a common way to do development these days to break down the app in modules. This way modules can be used in other version of the APP without recompiling etc. etc.

If we call it a wrapper, a plugin, module whatever. Only the devs. can explain it.

P

Cool,

This is definitely an area that only the devs can explain clearly for us, and whether the module is in fact adding an extra arbitration layer .

There is something definitely different in the overall behaviour of a lot of VST2.x plugs.

The other thing that is quite concerning is the commentary about needing to disable Multiprocessing, if that isn't throwing out the baby with the bath water, I don't know what is.. :-(

My suspicion that has more to do with the UAD1's - ducks, puts on a helmet.

[TAFKAT]

It sounds like it is two different issues if I am understanding it correctly then. An issue when it actually glitches the audio playback and the issue Fredo is describing where it is just glitches in phase cancelled audio but not actual glitches in sources.

.. see , you are getting better at deciphering the diagonalese.. :-)