Use case + Background info

I have recently come upon a few use cases where I found that the Param implementations included with nih-plug are not super well-suited, so I wanted to implement a custom Param.

However, I found a few things that I did not expect: The as_ptr method requires me to construct a ParamPtr instance, which is not possible for fully custom implementations since the possible types of parameters are hard-coded in nih-plug. Still, as I was delegating a bit of my Params basic functionality to an IntParam anyway, I could return something like self.inner.as_ptr() here.

Next, I found that a few methods from my Param implementation were never called (normalized_value_to_string, string_to_normalized_value). As far as I see, these are only ever called through ParamPtr - so even though I have to provide these functions, they are never used. For my concrete case, I could also hack around this by customizing my underlying IntParam using with_value_to_string and with_string_to_value.

The actual questions

Implementing Param out-of-tree seems rather unergonomic to me. Am I missing some obvious alternative here? Is this currently an intended use of Param at all?

Looking through the code, it appears that this if statement is executed every single frame for every single parameter:

https://github.com/robbert-vdh/nih-plug/blob/master/src/param/smoothing.rs#L198

It would be better if somehow this if statement is only executed once per parameter per process cycle.

I still vouch for baseplug's method which is to fill a buffer with smoothed values for each parameter beforehand. I can help you with it if you want.

https://github.com/wrl/baseplug/blob/trunk/src/smooth.rs#L47

It seems that MacOS is caching the old executable when we attempt to replace the binary. It looks like it requires the whole .app be deleted and replaced in order to run a new compilation.

You should definitely add the ability for a parameter to translate its value using util::db_to_gain before smoothing it.

The current gain example is woefully inefficient since it is converting from db to gain every single sample:

for channel_samples in buffer.iter_samples() {
    // Smoothing is optionally built into the parameters themselves
    let gain = self.params.gain.smoothed.next();

    for sample in channel_samples {
        *sample *= util::db_to_gain(gain);
    }
}

This is how baseplug implements this: https://github.com/wrl/baseplug/blob/trunk/src/parameter.rs#L116

Hi, thank you for making free plugins, I'd like to try them. I found a link from a youtube video and tried to install on my MacBook Pro M1 with Ableton Live 11 and Ableton Live 10 and neither one showed the plugins in Ableton's browser. I followed Ableton's help instructions and none of them worked, do you know what might be wrong? Thanks

This is a bit of a smart ass "issue" but in "https://github.com/robbert-vdh/nih-plug/blob/master/src/midi.rs" the channel of NoteEvent (For messages that have a channel) is declared as:

    /// The note's channel, from 0 to 16.
    channel: u8,

It should probably read 0 to 15 (4-Bit) if it is zero based or 1-16. From my experience it is zero based.

https://www.cs.cmu.edu/~music/cmsip/readings/MIDI%20tutorial%20for%20programmers.html

What's the best way to add logging (to a log file) to a plugin? I tried the following, which works with rust vst2 (adapted from https://github.com/DGriffin91/egui_baseview_test_vst2). It creates the log file, but doesn't log anything to it:

use simplelog::{Config};

pub(crate) fn init(name: String, version: i32) {
    if let Some(local_dir) = dirs::data_local_dir() {
        // check if clockwork-vst folder exists, if not create it
        let mut path = local_dir.clone();
        path.push("clockwork-vst");
        path.push("logs");
        if !path.exists() {
            std::fs::create_dir_all(&path).ok();
        }

        let logging_dir = path.clone();
        if logging_dir.exists() {
            let filename = format!("{name}-{version}-log.txt");
            let log_file_path = logging_dir.join(filename);

            if let Ok(log_file) = std::fs::OpenOptions::new()
                .append(true)
                .create(true)
                .open(&log_file_path)
            {
                simplelog::WriteLogger::init(simplelog::LevelFilter::Info, Config::default(), log_file)
                    .ok();
                log_panics::init();
                log::info!("Starting VST");

            } else {
                panic!("Could not open log file");
            }
        }
    }
}

OS: macOS 12.2.1 DAW: REAPER 6.49

First of all, thank you for building this framework. It looks very cool.

I wanted to try out gain_gui, so I built it using cargo xtask bundle gain_gui --release --bundle-vst3, then copied target/gain_gui.vst3 to /Library/Audio/Plug-Ins/VST3.

While the plugin works, the cursor position appears to be off. This is most obvious with the slider, which isn't draggable unless I drag on a specific spot below the handle. Maybe a scaling issue?

https://user-images.githubusercontent.com/4495237/155819619-16238ac4-b580-4ccf-827a-3e09e10bee58.mov

I understand that this stuff hasn't been tested on macOS, so feel free to close this issue if it's not actionable :)

The skew_factor functions inside of FloatRange are not currently const. This means they can't be used when creating FloatRange's in a const context, meaning they can't be used for FloatRange::Reversed.

Minimum reproduction:

use nih_plug::prelude::*;
use std::sync::Arc;

static RATIO_RANGE: FloatRange = FloatRange::Skewed {
    min: 0.0,
    max: 1.0,
    factor: FloatRange::skew_factor(-1.0),
};

#[derive(Params)]
struct PluginParams {
    pub param: FloatParam,
}

impl Default for PluginParams {
    fn default() -> Self {
        Self {
            param: FloatParam::new(
                "param",
                1.0,
                FloatRange::Reversed(&RATIO_RANGE),
            )
        }
    }
}

This resolves issue #43. Nested parameters that are not grouped are now inserted to the parameter list according to definition order. Grouped parameters remain at the bottom of the parameter list.

How to reproduce

Have a plugin where the parameter struct contains "non-nested" parameters aft`r nested ones:

#[derive(Params)]
struct PluginParams {
    #[id = "one"]
    pub one: FloatParam,

    #[nested(group = "inner")]
    pub two_and_three: InnerParams,

    #[id = "four"]
    pub four: FloatParam,
}

#[derive(Params)]
struct InnerParams {
    #[id = "two"]
    pub two: FloatParam,

    #[id = "three"]
    pub three: FloatParam,
}

See also: minimal example plugin

Expected behavior

When opening the plugin in the host, the parameters are displayed in this order:

1. One
2. Two
3. Three
4. Four

Actual Behavior

The nested parameters from InnerParams are displayed after all non-nested parameters:

1. One
2. Four
3. Two
4. Three

See, for example, Bitwig:

First, great work ! I could get a vst3+clap plugin going in 5 minutes.

I'm trying to make a simple midi arpeggiator - one note in, multiple notes out. How would I emit a NoteOn midi event, let's say, one quarter noter later than the initial note received ? I'd love a quick sample.

Thanks !

I want to be able to enter an environment and be able to build for all targets with no extra setup.

Currently cross compiling isn't smooth, and setting up an environment with the correct development dependencies is not always straight forward.

Nix Flakes are great for this, but a Dockerfile (where I have started) works too, albeit not as nice to work with as Flakes.

It's taken me a few days to figure out the linux/linux and linux/windows build environments. Not sure how far I'll get with osx pipeline.

I also want to thank you so much for putting all this together. I've been dreaming of making a VST for about 10 years and now I feel I'm able to. Besides setting up the environment, you've made it a straight forward process <3.

# Can build linux and windows, gain_gui_iced
FROM rust

RUN apt-get update  \
    && \
    apt-get install -y \
    libasound2-dev \
    libgl-dev \ 
    libjack-dev \
    libxcb1-dev \
    libxcb-icccm4-dev \
    libxcursor-dev \
    libxkbcommon-dev \
    libxcb-shape0-dev \
    libxcb-xfixes0-dev \
    libx11-xcb-dev \
    libxcb-dri2-0-dev \
    curl \
    python3 \
    cmake \
    clang \
    gcc \
    g++ \
    zlib1g-dev \
    libmpc-dev \
    libmpfr-dev \
    libgmp-dev \
    gcc-mingw-w64 \
    && \
    rustup target add \
    x86_64-pc-windows-gnu \
    x86_64-apple-darwin \
    && \
    cargo install cross 


RUN git clone https://github.com/tpoechtrager/osxcross /usr/local/osxcross &&\
    cd /usr/local/osxcross && \ 
    wget -nc https://s3.dockerproject.org/darwin/v2/MacOSX10.10.sdk.tar.xz && \
    mv MacOSX10.10.sdk.tar.xz tarballs/ && \
    UNATTENDED=yes OSX_VERSION_MIN=10.7 ./build.sh 


ENV PATH "$(pwd)/osxcross/target/bin:$PATH"

WORKDIR /home/local/project

ENTRYPOINT ["/bin/bash"]

The assert_process_allocs feature is very useful you'll immediately know whether or not you're allocating in your process function. The problem is that while this does work, it can be tricky to know what is causing those allocations. We could improve this by having it use the logger instead of printing directly to STDERR, and to have it print a backtrace in addition to the allocation size.