wavecraft_plugin!() { /* proc-macro */ }Expand description
Procedural macro for generating complete plugin implementations.
This macro parses a minimal DSL and generates all the boilerplate code for
a working VST3/CLAP plugin. Plugin metadata is automatically derived from
your Cargo.toml.
§Syntax (0.9.0+)
use wavecraft::prelude::*;
// Define your processor wrapper
wavecraft_processor!(MyGain => Gain);
// Generate complete plugin with minimal boilerplate
wavecraft_plugin! {
name: "My Plugin",
signal: SignalChain![MyGain],
}§Metadata Derivation
The macro automatically derives plugin metadata from Cargo.toml:
- Vendor: First author in
authorsfield (or “Unknown”) - URL:
homepagefield (orrepositoryif homepage empty) - Email: Extracted from first author’s email in
authorsfield - Version:
versionfield (viaCARGO_PKG_VERSION)
Add metadata to your Cargo.toml:
[package]
authors = ["Your Name <your.email@example.com>"]
homepage = "https://yourproject.com"§Optional crate Property
If you’ve renamed the wavecraft dependency in your Cargo.toml:
[dependencies]
my_wavecraft = { package = "wavecraft-nih_plug", ... }Then specify the renamed crate:
wavecraft_plugin! {
name: "My Plugin",
signal: SignalChain![MyGain],
crate: my_wavecraft, // Optional
}§Breaking Changes (0.9.0)
- Removed
vendor,url,emailproperties (now auto-derived) - Bare processors no longer accepted: use
SignalChain![...]wrapper - VST3 Class IDs now use package name instead of vendor (plugins get new IDs)
- Default
cratepath changed from::wavecraft_nih_plugto::wavecraft
See docs/MIGRATION-0.9.md for migration guide.
§Known Limitations
Parameter Automation: The DSL-generated process() method always receives
default parameter values. Host automation and UI work correctly, but the
Processor cannot read parameter changes.
Workaround: For parameter-driven DSP, implement the Plugin trait directly
instead of using this macro. See SDK documentation for examples.
Tracking: This limitation is tracked in the SDK roadmap for future releases.