How to a paint a box?

[SephReed]

I don't need a full UI system, I can build one from scratch. I just need to be able to paint a box, and from there I can figure it out.

How do I get the vst to paint a box (in the simplest possible code)?

[crsaracco]

It's a hard problem to do in a platform-independent way. I have some information about the problem space here.

If you want to just make VSTs for yourself, here are some platform-dependent prototypes. It's going to be a lot of very-low-level platform GUI code.

[SephReed]

Hmmm... how low is low level? If it's "here's a box, draw some pixels" I can do that. But writing shaders is not something I'm used to.

[SephReed]

https://github.com/crsaracco/vst2-gui-research/blob/master/gui-from-scratch.md

I'm super down to help, and I have a goal in mind:

Fill a rectangle with a gradient.

If we can do that, we can do anything.

---

Also, I think we should use "Strategy Pattern" to loosely couple the means of fulfilling these functions and the place's they are called. It's similar to having conditional code for platforms, but by wrapping each strategy in an isolated globally retrievable package, it makes it so adding new strategies is much, much simpler. Also, a lot less spaghetti condition stuff. And way less likely to get collision between two devs on different systems.

[crsaracco]

"Low-level", here, is implementing the entire window system stack yourself:

• Using the platform-native window creation function (Windows, Mac OS, X11), while attaching it to the window that the DAW gives you
• Setting up some sort of draw surface, like a raw OpenGL surface, or maybe something like cairo-rs
• Making sure that events work, like clicking and typing
• And probably a whole bunch of other miscellaneous low-level window management stuff that I can't think of right now (DPI scaling? etc)

After that, you're ready to draw a rectangle, via whichever surface API you chose.

If you just want to make VSTs that you create only for yourself to use, it's a decent amount of work to spin up a nice re-usable crate -- maybe O(weeks) to O(months) depending on how dedicated you are and how much time you're willing to dump into it -- but it's not too bad.

If you want to create something that everyone can use to create VSTs for users on all systems, then all of the external APIs need to be platform-independent, and all features need to work roughly the same on all systems (as much as possible, at least). This gets very complex very quickly, because of how all three systems handle window creation, events, etc. differently.

Any crate released under RustAudio would need to fall under this latter category.

---

Right now, I'm very interested in tweaking Druid to get it working for VSTs. It currently looks the most viable for our use-case, but there is still a decent amount of work to be done. I have some issues in the issue tracker currently:

• #475 - "Add a native X11 backend" since currently Linux uses GTK, which won't work for VSTs.
• #468 - "Support for attaching to a parent window" since currently there's no API in druid to do this, and VST GUIs need this feature.

After these two things are done, we should be pretty close to making GUIs work for rust-vst, although there is still likely a little bit of work left to do (I think we'll need to end up tearing out the event loops and making our own custom Application structs out of the result, or something).

I've been working on the first bullet point a little bit whenever I have good chunks of time, but those seem to be pretty rare these past few weeks.

---

I can't speak to the pros/cons of the Strategy pattern in particular, but I do know that conditional code / conditional modules is (as far as my experiences go) a pretty common pattern in Rust GUIs. I think I'd have to see a proof-of-concept for the Strategy pattern to comment further here.

[SephReed]

The strategy pattern applies more to stuff like: "How to draw a box" or "How to draw a circle." The idea being, if someone has a fancy idea on how to draw a circle, they can implement it as a strategy and then use configuration to say "use this method." If it turns out that strategy is better, it can become the default. Then, if something goes wrong down the line, it doesn't require git history to go back, just a switch of strategy.

---

You said elsewhere that you've managed to make a project on Linux, Win, and Mac that had some form of GUI, did I read that right?

If so, it seems like using that as a base, then having the different versions of piet (https://github.com/xi-editor/druid#piet) accessed by OS specific strategies to do stuff like drawCircle() or fillRect() would perhaps be enough to get a red box on screen for a few of the os types.

Of course there'd still be the event system. There's also probably more events than I'm thinking of (currently mousemove, mousedown, mouseup, mousescroll, keydown, keyup)

---

Sorry if anything I say is ridiculous. I'm trying to get a grasp of this project. It seems a lot, but well worth it in the end.

[crsaracco]

You said elsewhere that you've managed to make a project on Linux, Win, and Mac that had some form of GUI, did I read that right?

If so, it seems like using that as a base [...]

Yep! That was the idea when I started the project -- figure out what needs to be done on all three, then combine them into one nice crate.

(I didn't get Mac in VST form, but others have done so in the past, so I'm not worried about it)

[...] then having the different versions of piet (https://github.com/xi-editor/druid#piet) accessed by OS specific strategies to do stuff like drawCircle() or fillRect() would perhaps be enough to get a red box on screen for a few of the os types.

I think Piet pretty much does that for you -- you just create whichever surface you need (direct2d or cairo), feed it into Piet, and then call Piet API functions after that. That's what Druid is doing under the hood, anyway.

Of course there'd still be the event system. There's also probably more events than I'm thinking of (currently mousemove, mousedown, mouseup, mousescroll, keydown, keyup)

I feel like Druid is already ~90% of the way there (along with the drawing stuff from the previous quote), which is why I'm interested in trying to shape it the rest of the way there to our needs.

---

Anyway, I think we're getting a little off-topic for the vst-rs issue tracker; this is starting to dive into more of a "GUI crate design" territory. Happy to talk more about it on #vst2-gui on our Discord if you like!

[Boscop]

@SephReed If you are on Windows, the easiest way would be using this:
https://github.com/vanderlokken/rust-vst-gui

E.g. I used it for this VST where I really needed a GUI (usually I don't need a GUI):

(I use this VST to split midi channel 10 between different drum synths/samplers.)

[SephReed]

I'm on MacOS, developing something I'd like to run headless on RaspberryPi (Ubuntu).

I don't technically need a GUI, but it makes testing (like play, not so much unit) sooooo much easier.

[rjwittams]

I'm working on this in Druid. Mac for now, and that is on a branch of druid.
https://github.com/rjwittams/druid-vst

[piedoom]

GUI situations have much improved! Please check out iced-audio and egui-baseplug