Optional standalone format by emuell · Pull Request #12 · ilmai/plugin-things

emuell · 2026-03-25T20:03:58Z

Adds a new optional standalone crate feature, which adds a new 'Standalone' plugin format and plugin export.

The standalone impl uses:

CPAL for audio output
midir for note input (to trigger synths);
winit to create a basic host window so it works on macOS, Windows and Linux

It will be difficult to add a custom GUI for MIDI and audio settings, so right now CPAL uses the audio host with the default audio device, which usually works just fine. As there is no such thing as a default MIDI device the standalone tries to open all MIDI input devices and forwards all MIDI events from each device to the plugin.

The editor is attached to a bare-bones window created by winit, and scaling is set as most host would do.

Duplex audio isn't possible with CPAL right now, but we could allow a wav file to be loaded via a program argument, which would then be looped forever as the audio input for FX. But I don't really need that, so I skipped it.

Note that this is a very basic implementation, and isn't intended for release to users but just eases development and debugging. I find that especially useful in combination with Slint's live preview feature.

To document how to use the live preview feature and bundling, for example, I've added a justfile as well. I personally use them everywhere, because they help me to remember commands when switching between projects. Let me know if you would prefer me to remove it.

Also totally fine if you think a standalone target is not worth maintaining. I'll then simply keep it in my branch for testing...

btw: I find it very hard to follow your code formatting style. I usually run cargo fmt on save, but this messes up your formatting. Maybe you could add some custom cargo fmt rules to ease that?

ilmai · 2026-04-22T11:01:57Z

I would prefer not to have tool-specific files like justfile in the repo

ilmai · 2026-04-22T11:02:42Z

In general, I think having a standalone version for testing is a good idea. Lack of duplex audio in cpal is somewhat of a blocker but apparently it should be landing soon: RustAudio/cpal#1096

ilmai · 2026-04-22T11:07:02Z

The fact that it's currently opening all MIDI input devices doesn't feel optimal; on Windows up until a recent Windows 11 update, MIDI device access is exclusive so running this would block all MIDI input for other applications unless they already had the device open. As long as this is only for testing, it's not a huge issue of course, but if we think about extending this feature to support standalone releases like some plugin instruments are doing, this isn't acceptable. What I would do is that instead of a macro to automatically generate a main function and application, have the developer write the main function themselves and call a function to set up things like device selection. It doesn't have to be all there at once, but I would drop the macro from this PR and use the manual main function method instead. Then add device selection and probably other features later.

ilmai · 2026-04-22T11:08:07Z

Oh and also, I have "run everything through rustfmt and start doing formatting on save" on my TODO list, just haven't gotten around to that yet. Don't worry about matching my formatting.

- optional feature, disabled by default - CPAL for audio IO, opening the default device with default settings - midir for note input, opening the first available MIDI input device - winit to create a slint host window

to ease building and testing the gain-plugin example

emuell · 2026-04-22T12:09:16Z

The fact that it's currently opening all MIDI input devices doesn't feel optimal

Yep, that's indeed quite a hack, but it avoids creating config files or passing cmd line args, or adding a config GUI.

The proper version of it would be adding a Slint GUI for that - embedding the plugin view into some custom GUI, but that's out of scope for this PR. Everything else, env variables, config files or cmd line args, do not really fix anything, as we need to get the names of the devices from somewhere in order to specify them.

Fine with me to drop the main macro, but there's also no need to use it in case you need a custom main.

What would work for you now, a compile-time or run-time option to avoid opening up all MIDI devices?

ilmai · 2026-04-22T12:20:03Z

Fine with me to drop the main macro, but there's also no need to use it in case you need a custom main.

I think having the developer write a custom main function instead of using a macro feels like the correct choice in the long run since for anything except quick and dirty development builds the macro can't really do everything that's needed.

What would work for you now, a compile-time or run-time option to avoid opening up all MIDI devices?

Current behavior is fine for now! I just think going the manual main function route and offering an API for querying available devices etc. is the only good solution down the line so let's start on that road now.

emuell · 2026-04-22T12:30:06Z

What about adding a standalone 'run' function (and skipping the main macro) that takes a 'config' argument, to make that clear? The config's default impl will use be set up to use the default audio device and opens all MIDI devices, so the easy, default option oasth is then one we have now but allow configuring it somehow.

I could give this a try later this week...

ilmai · 2026-04-22T12:32:53Z

Yeah I was thinking of a similar solution, sounds good. We can always support more complex scenarios later.

…io thread

emuell · 2026-04-22T20:40:15Z

Added assertions, logs for the audio allocs as discussed, as well as a basic README to the gain example to clarify how it can be built (bundle vs. standalone) now that the justfile is gone. I don't think this is obvious, and it will help people who are new to all this.

Please change the README as you see it fit or remove it, if you don't want it there.

Going to take a look at the standalone config stuff later this week or next week.

… devices programatically

emuell · 2026-04-24T10:42:43Z

Added audio and MIDI configs now, defaulting to default audio device and all MIDI inputs, as discussed.

Kept the export_standalone! just to add an example on how to override the default configs and how to use the device enumeration functions.

ilmai · 2026-04-24T11:41:47Z

        // Process audio, ensuring we don't call process with more than P::MAX_BLOCK_SIZE frames
+        debug_assert!(
+            self.buffer.capacity() == P::MAX_BLOCK_SIZE,
+            "Buffer must be preallocated to avoid allocation on the saudio thread"


Nitpick: typo "saudio"

ilmai · 2026-04-24T12:27:05Z

+    /// Returns all audio drivers available on this platform.
+    ///
+    /// Always includes [`AudioDeviceDriver::Default`], followed by any named drivers that are
+    /// currently available (e.g. ASIO, WASAPI on Windows; ALSA, JACK on Linux).


Comment about JACK doesn't match code below

ilmai · 2026-04-24T12:35:34Z

+        Ok(devices)
+    }
+
+    pub fn open_host(&self) -> Result<cpal::Host, Box<dyn std::error::Error>> {


Just a note: down the line I would prefer a type state based solution for opening devices etc. but for now I think this is good enough

I think we can get fancy here when someone actually starts using it :) Didn't wanted to bloat this unnecessarily now.

I'll remove the macro. Okay with you to add two run functions then run_standalone and run_standalone_with_config where run_standalone uses default configs?

Sounds good!

ilmai · 2026-04-24T12:40:02Z

@@ -1,8 +1,37 @@
+/// Generates a `main` entry point that runs the given plugin as a standalone application.


The documentation here is nice 👌

However I still think that having a macro for something that's a one-liner with the default config is not a good choice. The documentation could be in standalone.rs and possibly on the front page when we have proper docs at somepoint.

ilmai · 2026-04-24T12:42:15Z

+    } else {
+        for port in &ports {
+            let name = midi_in.port_name(port).unwrap_or_else(|_| port.id());
+            log::info!("Available MIDI input port: '{name}'");


"debug" feels like a more approriate log level here as this is potentially spammy

…standalone_with_config` with examples in comments

emuell · 2026-04-24T13:34:16Z

Oh, btw. I didn't enable PipeWire and PulseAudio CPAL backend features, because I don't need them. Please add them if you need them. The changes in standalone/config.rs will be minimal...

emuell · 2026-04-24T13:36:56Z

A dedicated error type for Audio/MIDI related errors from the config also wouldn't hurt. Please add them as you seem this fit later...

emuell marked this pull request as draft March 26, 2026 08:44

emuell force-pushed the feature/standalone-app branch from 208f79a to 872d5d3 Compare April 2, 2026 20:29

emuell force-pushed the feature/standalone-app branch from 872d5d3 to 56dfdbb Compare April 13, 2026 07:06

ilmai requested changes Apr 22, 2026

View reviewed changes

emuell added 3 commits April 22, 2026 13:24

Add new standalone plugin format

fbfa75c

- optional feature, disabled by default - CPAL for audio IO, opening the default device with default settings - midir for note input, opening the first available MIDI input device - winit to create a slint host window

Add standalone target for the gain example

a0e463e

Add justfile

60fe046

to ease building and testing the gain-plugin example

emuell added 2 commits April 22, 2026 14:16

Don't send Start/EndParameterChange events to plugins

ecb61fc

Revert xtask changes and remove/ignore justfile

eef5489

emuell force-pushed the feature/standalone-app branch from 56dfdbb to eef5489 Compare April 22, 2026 12:17

emuell added 2 commits April 22, 2026 22:20

Log (for events) or assert (for audio buffers) allocations on the aud…

fb8f4e3

…io thread

Add README for the gain example to make clear how to build it

7bc59ae

emuell added 2 commits April 22, 2026 22:47

Add TODO for StandaloneParameterEventIterator's next impl

d2738ba

Add audio and MIDI configs and enumerate functions to allow selecting…

6625f0f

… devices programatically

emuell marked this pull request as ready for review April 24, 2026 10:42

ilmai requested changes Apr 24, 2026

View reviewed changes

emuell added 2 commits April 24, 2026 15:14

Removed some logging & fixed some comments

0408af6

Remove export_standalone macro & add new run_standalone and `run_…

2b92145

…standalone_with_config` with examples in comments

		@@ -1,8 +1,37 @@
		/// Generates a `main` entry point that runs the given plugin as a standalone application.

Conversation

emuell commented Mar 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ilmai commented Apr 22, 2026

Uh oh!

ilmai commented Apr 22, 2026

Uh oh!

ilmai commented Apr 22, 2026

Uh oh!

ilmai commented Apr 22, 2026

Uh oh!

emuell commented Apr 22, 2026

Uh oh!

ilmai commented Apr 22, 2026

Uh oh!

emuell commented Apr 22, 2026

Uh oh!

ilmai commented Apr 22, 2026

Uh oh!

emuell commented Apr 22, 2026

Uh oh!

emuell commented Apr 24, 2026

Uh oh!

ilmai Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

ilmai Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

ilmai Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

emuell Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

ilmai Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

ilmai Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

ilmai Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

emuell commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

emuell commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

emuell commented Apr 24, 2026 •

edited

Loading