BR: Mu.Lab doesn't recognize Waves Waveshell 9.2

[pljones]

I was under the impression (from what I've read elsewhere) that Waves plugins required their own plugin format for native access. Any non-native access (be it Waveshell or allowing a VST-only host to access a DX or AU plugin) is going to be fraught with compatibility issues as there are so many potential points of failure (the host to container protocol being correct in two directions for each version of the host to container protocol on both sides, the container to plugin protocol being correct in each of two directions for each version of the container to plugin protocol on both sides - doesn't really bear thinking about). Such a container's compatibility with hosts and plugins can only be the responsibility of the container author, too - they are in control of changes to it, so it would be unreasonable to expect anyone else to bear that burden.

[whyterabbyt]

I was under the impression (from what I've read elsewhere) that Waves plugins required their own plugin format for native access.

No; as far as I understand it, shell plugins (or single plugin files with multiple plugin entry points) are supported within most of the plugin standards. Hence the existence of support for shell plugins within the standards eg the following appropriate VST2 canDo

const char* canDoShellCategory = "shellCategory"; ///< 'shell' handling via uniqueID. If supported by the Host and the Plug-in has the category #kPlugCategShell

#

and shell-supporting VST2 callbacks.

2. audioMasterCurrentId >= VST1.0 @see AudioEffect::getCurrentUniqueId()
plugin requests host for current unique identifier
x[return]: current unique ID of a shell plug-in (in VST2.3 x[return]: the unique ID of the plug that is currently loaded)

[pljones]

The WaveShell is a single on-disk plugin of whichever format, which, when scanned by the host, effectively 'contains' the list of effect/synth plugins the user has installed and authorised.

So internally Waves uses its own format but tries to provide a container that looks like VST, etc. Which is sort of what I'd said, I think. I hadn't understood that VST was "meant" to understand this -- the VST2.4 "shell" stuff (getNextShellPlugin)... I guess I didn't understand what that was for when I read the overview so never dug into it. I'll shut up now

[akeia]

Unfortunately I cannot work on my Mac with the Waveshell 9.2. from Waves. Simply not recognized....

It is possible to host "DDMF Metaplugin" within MUX. Metaplugin allows hosting of Waves Shell Plugins correctly. And by the way also VST3 and AU plugins. Meaning you can mix and match AU, VST, VST3, Waves-Shell-VST and MUX plugins within a MUX patch. I would guess that means it works in MuLab also but I do not have it to test.