Wavelab && 2015-12-1 VST plugins: Removed old but flawed workaround for detecting offline mode

Audio Plugins
1

Is is true, that removing this workaround, stops the setNonRealtime(…) in current WaveLab 8.5 Windows.
So what was the reason to remove the workaround, is there a better method for WaveLab now?
And if there was no reason, why removing this workaround?
The big problem is, costumers relying on the behavior, now it just stop working :frowning:

So if wavelab doesn’t report the offline mode properly, did someone tell the WaveLab developers in the last years, to fix this? Someone?

#if JUCE_WINDOWS
       if (GetThreadPriority (GetCurrentThread()) <= THREAD_PRIORITY_NORMAL
              && GetThreadPriority (GetCurrentThread()) >= THREAD_PRIORITY_LOWEST)
            filter->setNonRealtime (true);
#endif
2

Aha! So WaveLab was the culprit!

Check the discussion about that here and also here

tl;dr: it is a poor way to detect non-realtime processing, it also leads to wrong detection in other hosts (SONAR is sure one of them) and should be avoided in my opinion.

If compatibility with WaveLab is an issue, then restricting that patch ONLY to WaveLab on Windows is a must, in order not to mess with other hosts that support the VST protocol way to report non-realtime processing properly

EDIT: also, adding a specific ‘if’ that checks the host to which the workaround applies, leaves a very useful trace in the code of the host for which the workaround is necessary. It is a nice thing to have when looking back at old code to understand why it was put there. (aside from, obviously, proper documentation with comments)

3

I recommend if somebody finds a bug or misbehavior in a plugin host, please TALK to the developers of the host. Most of them are nice people! There is a real chance to get rid of the workarounds.

2 Likes
4

So for the moment just?

                #if JUCE_WINDOWS
			const PluginHostType host (getHostType());

			if (host.isWavelab() && GetThreadPriority (GetCurrentThread()) <= THREAD_PRIORITY_NORMAL
				&& GetThreadPriority (GetCurrentThread()) >= THREAD_PRIORITY_LOWEST)
				filter->setNonRealtime (true);
		#endif
1 Like
5

Ah yes, WaveLab. @chkn, WaveLab is the one DAW where I wouldn’t waste my time asking them for help, based on previous experience.

But thanks for the discussion, guys, it does sound like re-adding this for WaveLab only would be a sensible workaround.

6

There should be an open document, ideally inside the git repository, which collects all information about weird host-behavior.

So nobody has to search in the forum several hours, and as a central point of information for plugin-developers/host-developers/customers

7

You are talking about Steinberg man

1 Like
8

There should be an open document, ideally inside the git repository, which collects all information about weird host-behavior.

This sounds like a great idea. I think a Google doc may be better though as it allows everyone to collaborate.

9

everyone with a google account :wink: Or just simple *.txt-file in a separate git repository?

10

Locating it in the git repo seems like a more sensible idea, so it is possible to track its history easily and relate it with fixes/workarounds in JUCE.

Also, I’d avoid letting it be a public document where everyone can collaborate, it’s too high the risk that this will transform it into a makeshift (and poor) bug reporting system: what one sees as one particular host’s quirk, could in reality be a JUCE bug and vice-versa.

I’d start by putting in it the remarks on various hosts and formats that have been added at the bottom of the multibus guide post: that seems to me like the perfect style for that document to have

11

For collaborate host document please take this detour: collaborate document for host specific behaviour
Thanks

@fabian, @yfede, @chkn: sorry, can you post there again or copy there? That way we can follow that discussion and maybe it will become true… hopefully…