VST3 C API

[superelectric]

Hey all, currently messing around with writing a plugin using Zig (https://ziglang.org/), so far I've just been using CLAP because the API is really clean and easy to implement, but I'd like to also be able to compile the plugin as a VST3 for compatibility reasons. I was wondering if anyone has actually tried implementing the VST3 C API Steinberg put out last year (https://github.com/steinbergmedia/vst3_ ... ree/master), it seems to be a pretty heinous mess of manual vtable setups and stuff. I'd really like to have my whole codebase just in Zig, and having to write a C++ wrapper that just consumes my CLAP plugin seems overkill. Anyways any resources/advice on this welcome. Feel free to tell me this is a horrible miserable idea as well

[keithwood]

It looks like it would be cumbersome. Given that the VST3 SDK has been annotated so that a tool can process the C++ API and produce the single file C API. It should be possible to write a similar tool to create a cleaner single file C++ API based on the source code for the C generator. That could lead to a good outcome and possibly within the VST3 licensing terms...

[S0lo]

There is a clap wrapper: https://github.com/free-audio/clap-wrapper

[superelectric]

It looks like it would be cumbersome. Given that the VST3 SDK has been annotated so that a tool can process the C++ API and produce the single file C API. It should be possible to write a similar tool to create a cleaner single file C++ API based on the source code for the C generator. That could lead to a good outcome and possibly within the VST3 licensing terms...

I'm not sure I follow? Are suggesting that it would be easier to generate my own C API than to use the one generated by Steinberg? Also what licensing benefits would that have?

There is a clap wrapper: https://github.com/free-audio/clap-wrapper

Yeah I'm familiar with this although there's no documentation right now on how to get it to spit out a fully packaged up VST3, the only option with documentation is creating a VST3 that dynamically loads the CLAP shared library. Also the bigger reason for avoiding this is adding a C++ dependency in my codebase, although frankly it seems like that might be unavoidable given how poorly documented the C API is.

[keithwood]

It looks like it would be cumbersome. Given that the VST3 SDK has been annotated so that a tool can process the C++ API and produce the single file C API. It should be possible to write a similar tool to create a cleaner single file C++ API based on the source code for the C generator. That could lead to a good outcome and possibly within the VST3 licensing terms...

I'm not sure I follow? Are suggesting that it would be easier to generate my own C API than to use the one generated by Steinberg? Also what licensing benefits would that have?

I was assuming that you don't really want to write everything in C but are yearning for a simple VST3 interface. If you do want to write everything in C, ignore me

[superelectric]

I was assuming that you don't really want to write everything in C but are yearning for a simple VST3 interface. If you do want to write everything in C, ignore me

You're correct that I'm not planning on writing it in C . The plan is to write it in Zig, which has really good C interop. It means that with something like CLAP (which is just a C API), I can do:

Code: Select all

const c = @cImport({
    @cInclude("clap.h");
});

And I'm able to use all the types from the "clap.h" header without having to worry about the usual ABI compatibility stuff. I can do the same with the C header Steinberg distributes, but like I said I haven't been able to find any examples of how one goes about implementing a basic plugin using the interface. Obviously I need to fill out the appropriate structs and their vtables, which is simple enough, but all of the C++ examples make use of macros that don't exist in the C API (presumably because they use C++ features). Anyways I'm probably just going to go and expand those macros and try to figure out which structs I need to expose and go from there, w as just wondering if anyone was silly enough to have tried something like this before .

[BertKoor]

Silly suggestion probably: use JUCE with zig?

[superelectric]

Silly suggestion probably: use JUCE with zig?

I don't think there's Zig bindings for JUCE, and even so I don't love taking on such a big dependency. I might wrap the CLAP plugin in a JUCE app for the time being, just so that I can test in DAWs that don't support CLAP yet. But long term I'd like to be providing my own backends for whatever plugin formats I choose to support (this is less of a business decision and more because it appeals to the hacker within me ).

[keithwood]

You're correct that I'm not planning on writing it in C . The plan is to write it in Zig, which has really good C interop. It means that with something like CLAP (which is just a C API), I can do:

Code: Select all

const c = @cImport({
    @cInclude("clap.h");
});

Gotcha. A useful reference might be the port of the VST3 API in Rust: https://github.com/RustAudio/vst3-sys

There's a good example of how a plugin is put together from the COM interfaces:https://github.com/RustAudio/vst3-sys/b ... src/lib.rs

[superelectric]

You're correct that I'm not planning on writing it in C . The plan is to write it in Zig, which has really good C interop. It means that with something like CLAP (which is just a C API), I can do:

Code: Select all

const c = @cImport({
    @cInclude("clap.h");
});

Gotcha. A useful reference might be the port of the VST3 API in Rust: https://github.com/RustAudio/vst3-sys

There's a good example of how a plugin is put together from the COM interfaces:https://github.com/RustAudio/vst3-sys/b ... src/lib.rs

That's super helpful, looking forward to digging in. Thanks so much!