MVC audio plugin framework for rust

The existing implementation of the offset_of! macro dereferences a null pointer, which invokes undefined behavior and results in a compiler warning. Change it to use addr_of! on a MaybeUninit instead.

Compiler Explorer shows this compiling down to a single lea instruction with optimizations on, so performance should not be an issue: https://godbolt.org/z/57deqbaM5

Figured out how to fix issue #29. It was a matter of figuring out where it wanted me to put the where Self: 'proc, P: 'proc, T: 'proc like it said in the error message.

Figured out how to fix issue #29. It was a matter of figuring out where it wanted me to put the where Self: 'proc, P: 'proc, T: 'proc like it said in the error message.

I'm using the RustyDAW org account for this since I've already forked baseview with my own account.

I have updated to the latest rust nightly compiler, and baseplug now fails to compile with the following error:

error: Missing required bounds on Process
  --> src/model.rs:11:5
   |
11 |     type Process<'proc>;
   |     ^^^^^^^^^^^^^^^^^^^-
   |                        |
   |                        help: add the required where clauses: `where P: 'proc, Self: 'proc, T: 'proc`

error: could not compile `baseplug` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

Baseview requires a struct that implements HasRawWindowHandle, which means the user must convert the RawWindowHandle given in PluginUI::ui_open() into a struct that implements that. This PR fixes that by converting it at the baseview level.

It is called TrustedWindowHandle because of it mirrors this: https://github.com/rust-windowing/raw-window-handle/blob/master/src/lib.rs#L210. I don't believe that this is in crates.io yet, so I created a temporary one.

Instead of the user doing this:

fn ui_open(parent: RawWindowHandle) -> WindowOpenResult<Self::Handle> {
    let settings = iced_baseview::Settings {
        window: WindowOpenOptions {
            title: String::from("iced-baseplug-examples gain"),
            size: Size::new(Self::ui_size().0 as f64, Self::ui_size().1 as f64),
            scale: WindowScalePolicy::SystemScaleFactor,
        },
        flags: (),
    };

    // TODO: Fix this mess in baseplug.
    struct ParentWindow(RawWindowHandle);
    unsafe impl HasRawWindowHandle for ParentWindow {
        fn raw_window_handle(&self) -> RawWindowHandle {
            self.0
        }
    }

    let handle =
        iced_baseview::IcedWindow::<ui::GainUI>::open_parented(&ParentWindow(parent), settings);

    Ok(handle)
}

They can now do this:

fn ui_open(parent: &impl HasRawWindowHandle) -> WindowOpenResult<Self::Handle> {
    let settings = iced_baseview::Settings {
        window: WindowOpenOptions {
            title: String::from("iced-baseplug-examples gain"),
            size: Size::new(Self::ui_size().0 as f64, Self::ui_size().1 as f64),
            scale: WindowScalePolicy::SystemScaleFactor,
        },
        flags: (),
    };

    let handle =
        iced_baseview::IcedWindow::<ui::GainUI>::open_parented(parent, settings);

    Ok(handle)
}

I believe it would be massively helpful to have a checklist that highlights the differences and similarities between plugin formats. This would both inform developers who aren't that familiar with plugin APIs (like myself) on how each of these work, and it will make how to create an abstraction over them much clearer.

I had to make assumptions on what the VST2 functions do. Feel free to add and correct me on them!

Creating a plugin implementation with:

const INPUT_CHANNELS: usize = 2;
const OUTPUT_CHANNELS: usize = 2;

that also implements MidiReceiver creates something that is flagged by Ableton and RENoise as an instrument with sidechain, when it should be an effect with 2 input channels. Does baseplug have a manual setting for this, like JUCE? Should this be a const in the Plugin trait?

This branch implements the Num, Real and Discrete traits to represent numbers. The main objective is to replace the Float trait which is not very well designed. I only implemented the basic operations to keep the current behaviour but it is of course possible to play others (All credit goes to SamiP for implementing these traits).

The next step would be to allow the use of other primitive types than f32. To do this, you have to play with the Translatable <T, P: Plugin, Model> trait.

I tried the following implementation but quickly found myself stuck:

impl <P: Plugin, Model, T> Translatable <T, P, Model> for T
    where T: Real + AsPrimitive <f32>.

This allows you to use f32 or f64. However, when we want to do the same thing for integers, we end up with a conflict:

impl <P: Plugin, Model, T> Translatable <T, P, Model> for T
    where T: Discrete + AsPrimitive <f32>.

We have two blanket implementations and this is not allowed by Rust until we can do mutual trait exclusions.

One solution that works is to implement the Translatable <T, P: Plugin, Model> trait for each type with a macro:

macro_rules! impl_real {
    ( $($t:ty),* ) => {
    $( impl<P: Plugin, Model> Translatable<$t, P, Model> for $t {
        fn xlate_in(param: &Param<P, Model>, normalised: f32) -> $t {
            ...
        }
    
        fn xlate_out(&self, param: &Param<P, Model>) -> f32 {
            ...
        }
    }) *
    }
}
impl_real! { f32, f64 }

macro_rules! impl_discrete {
    ( $($t:ty),* ) => {
    $( impl<P: Plugin, Model> Translatable<$t, P, Model> for $t {
        fn xlate_in(param: &Param<P, Model>, normalised: f32) -> $t {
            .
        }
    
        fn xlate_out(&self, param: &Param<P, Model>) -> f32 {
            .
        }
    }) *
    }
}
impl_discrete! { i8, i16, i32, i64, i128, isize, u8, u16, u32, u64, u128, usize }

With this solution, it is possible to use any scalar type to build a parameter.

I need your vision on which solution would be most appropriate in the context of the project.

Here is my attempt to implement enums in baseplug model. We can now write models like that:

baseplug::model! {
    #[derive(Debug, Serialize, Deserialize, Clone, PartialEq, Eq)]
    enum MyEnum {
        A,
        B,
    }

    #[derive(Debug, Serialize, Deserialize)]
    struct MyModel {

        #[parameter(name = "param")]
        param: MyEnum
    }
}

Nearly all the job is done in the proc macro.

There is one thing that I would like to improve but I haven't any solution right now. We now need to import baseplug::Translatable and baseplug::Param in the plugin since the proc macro generates the implementation of the Translatable trait for the enum.

Let me know what do you think and how I can improve it.

So far this seems to work for float parameters/entries (Smooth & Unsmoothed). I haven't yet figured out how to sync Declick parameters/entries yet, but this is a huge start.

Sorry if this PR is a bit of a mess. It took a lot of changes to get this working. :D

Hi, I'm the maintainer of rsynth, an "API abstraction for API's for audio plugins and applications". My "strategy" with rsynth was to stay away from UI's, hoping that others (with more expertise in UI development) would work on that. baseplug illustrates for me that this was the good strategy :-)

I'd like developers (including me) to be able to combine rsynth with baseplug for the UI for writing their plugins. What do you think about this?