Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VST3 com interface issue / fix #58

Closed
PolyVector opened this issue Mar 2, 2023 · 1 comment
Closed

VST3 com interface issue / fix #58

PolyVector opened this issue Mar 2, 2023 · 1 comment

Comments

@PolyVector
Copy link

Hello,
I found an issue with the VST3 com interface where any calls to create_instance() appear to return an IComponent, ignoring the IID that was requested. Typically this isn't a problem as the IComponent requested first, but the Steinberg AUWrapper requests an IAudioProcessor first, which wreaks havoc. For example, calls to audioProcessor->setProcessing() actually invoke get_bus_info() with nonsensical parameters. This was pretty difficult to figure out!

The vst3-sys project seems aware of this which I assume is why macros require IComponent to be listed first. Related issue for reference: RustAudio/vst3-sys#14

Here's a quick-and-dirty fix in wrapper/vst3/factory.rs. I'm sure there's a better way to do this, but I'm new to Rust.

    unsafe fn create_instance(
        &self,
        cid: *const vst3_sys::IID,
        iid: *const vst3_sys::IID,
        obj: *mut *mut vst3_sys::c_void,
    ) -> tresult {
        check_null_ptr!(cid, obj);

        if (*cid).data != P::PLATFORM_VST3_CLASS_ID {
            return kNoInterface;
        }

        //Fix: Returns the requested interface:
        let wrapper = Box::into_raw(Wrapper::<P>::new());
        if (*wrapper).query_interface(iid, obj) == vst3_com::sys::NOERROR {
            kResultOk
        } else {
            kResultFalse
        }
    }

Thanks for the wonderful work you're doing on NIH-plug, I'm really loving the combo with egui. 🍻

@robbert-vdh
Copy link
Owner

That's an oversight on my part, sorry! Don't know how I missed this, normally I'm super thorough with these kinds of things. I fixed this in a97c8ea. The caller can now properly create a properly object for any interface supported by the plugin.

5eqn pushed a commit to 5eqn/nih-plug that referenced this issue Nov 11, 2024
Not checking `iid` was an oversight, so if the host would create
anything other than `IComponent` this would do the wrong thing. With
this change the host can create an object for any interface we support.

Fixes robbert-vdh#58.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants