Open basdp opened 1 week ago
Hey, thanks for the compliment!
You're correct that resizing is not yet implemented for VST3, feel free to submit PRs for this or other bugs or missing features. If you're going to submit something that requires extensive changes, especially if it changes interfaces, it would be best to create an issue first so we can discuss the details.
Cool! I don't think resizing is complex to implement. I'll try something over the weekend!
Quick update; I got a dirty proof of concept of resizing the plugin window working on Windows. It didn't require any refactoring or other big things. I will test this on macOS in the coming days. I do not have a good Linux VST3 setup where I can test, but I own Bitwig which I can install in a Linux VM to test.
Probably will have to do resizes on CLAP and maybe AudioUnit too (saw there was some code in the AU format, but haven't seen it yet).
MacOS is also working now. Linux is next, but that requires a bit more effort as I don't have a Linux test bench setup. CLAP and AU are untested (and probably not working yet).
Linux/X11 too :-) Only one issue with Bitwig that is a known bug with Bitwig, see https://github.com/juce-framework/JUCE/commit/94330cbb533442818dce4e84100863f6574da0ce
For now I'm not going to solve it, but it might be trivial in the future to force a re-layout or something like JUCE is doing. All other DAW's I've tested on Linux have working resizing windows now (REAPER, Renoise, Ardour/Mixbus, Waveform).
@ilmai I think it would be a good idea to have a flag to enable or disable plugin window resizing. Currently VST3's are always resizable but that doesn't work (but I fixed that now), and CLAP is hardcoded to return false
for resizability.
What would be the best location for that flag to live?
My proposal would be to augment the Editor
trait like this:
pub trait Editor {
const DEFAULT_SIZE: (f64, f64); // <-- renamed
const IS_RESIZABLE: bool = true; // <-- new
fn set_scale(&mut self, scale: f64);
fn on_frame(&mut self);
fn set_window_size(&mut self, _width: f64, _height: f64) {} // <-- made optional with default no-op
fn window_size(&self) -> (f64, f64) { // <-- proposed new getter, defaulting to fixed DEFAULT_SIZE above
Self::SIZE
}
}
So renaming SIZE
to DEFAULT_SIZE
(debatable, alternative name could be INITIAL_SIZE
or just leave it as SIZE
) and adding the field IS_RESIZABLE
(proposed default true
, but also debatable). In the initial PR I have not renamed SIZE
, but added the IS_RESIZABLE
flag.
Also the plugin formats require a get_size (or equivalent) that we need to feed with the current size of the window if called. We could also get this value another way, but in my opinion this is most transparent to the dev, in line with the other functions in the Editor
trait.
Last but not least; plugin size and resizing is now 99% working and complete (~I'll open a PR later today to review~ PR is #3), but there is one thing that is still missing and that is restoration of plugin window size after close. This is rather trivial to implement by caching the last known plugin window size, but that needs to be done outside of the Editor
as it will not exist while the plugin is closed. Easiest is probably to do this in the format implementation files (e.g. plinth-plugin/src/formats/vst3/view.rs
for VST3 and plinth-plugin/src/formats/clap/extensions/gui.rs
for CLAP). I've left that out for now, but maybe you have a strong opinion on that and where/how to implement it.
I have opened a draft PR for this, see #3
It's still WIP, and the above stuff is still open for discussion.
Thanks for the effort, I've been super busy with other stuff but I'll take a look when it's a bit less hectic around here
Hi, I'm experimenting with
plugin-things
and having a lot of fun with it!It seems like window resizing is not working, at least for VST3 on Windows. I'm pretty sure because the
onSize
callback isn't doing anything. See: https://github.com/ilmai/plugin-things/blob/13fa1e501dcd0e9cb53348c3ba8d42ba9f535835/plinth-plugin/src/formats/vst3/view.rs#L140Are you aware of this?
Are you open to contributions? Then I can probably fix this (and perhaps other things) in a PR.