william light
william light
should look into https://crates.io/crates/log and whether it's feasible to create an implementation that works in plugin contexts.
in VST2 especially (since parameters are simply identified by their order), changing even the ordering can lead to broken automation. in plugin formats which have an opaque `u32` as their...
currently, baseplug leans on serde `Serialize + Deserialize` to persist the model state as JSON. however, this means that if the model for a plugin changes, there are potential issues...
got nothing right now. need to figure out rustdoc.
few pre-requisites for this: - [ ] `Param`s should have a hash (or otherwise opaque) `u32` ID instead of just an index. this allows for stable automation even when parameters...
VST3 and AU support arbitrary conversion of strings to and from parameter values, which are *not necessarily* the current value of the parameter. this is useful in situations where a...
currently, parameters are assembled in a flat array, which is how VST2 handles them. however, VST3 and AU support hierarchical arrangements of parameters addressed by opaque `u32` IDs, which keeps...
right now, i/o is fixed at [stereo in, stereo out](https://github.com/wrl/baseplug/blob/0a1be102bee96295f3a350f57b68bb2ce4f05f75/src/api/vst2.rs#L359-L360). this should be configurable somehow. imo, MVP on this is a fixed channel count defined in the `Plugin` impl block,...
Ideally, models should be able to have enums, nested structs, arrays, etc. The idea is for the `model!` macro to serve as a "scope" for everything associated with the model...
we should probably have this be dynamic (i.e. the plugin can change it during execution), but a fixed latency amount should be an alright place to start.