On starting developing for VCV

Hi,

Im a coder with some hardware synths out there and I would like to port some of them to VCV Rack. I would like to know what´s the common/fastest way to test/iterate the compilations while developing.

Do you have to open VCV after every iteration? Also Im used to visual studio code. It seems you can use it instead of Visual Studio but needs some more setup steps, is that correct?

Any tutorials on setting up VSCode?

I started to make a tutorial and didn’t finish it, but it might be useful…

2 Likes

Would be great if you pushed it further Dan

Yeah, the tuto seems fantastic. Im getting a bit overwhelmed for the amount of steps on it…

Its on my todo list…

1 Like

the tutorial is specifically how i do development on windows, some of the steps are optional in that sense (although I tried to write it so that you can follow it in order, most of the steps are one-time setup only)

the main parts you would need at minimum is installing Msys2, VSCode & the Rack SDK, with those you can then start writing code and you can run make from the msys terminal

I believe there are other ways to approach development (test driven dev mayhaps) but this is how I work normally

edit code > make install > run VCV and test the changes > close VCV > edit code > …

I don’t bother with make install until I need to test how my modules work with the whole ecosystem. I build/run Rack from source, along with a few select OSS plugins including Fundamental. I got used to this because there was a while where make install was broken on Windows.

I have VSCode on one monitor, and Windows Terminal on the other monitor, running two MINGW-64 tabs: one in the Rack folder, then other in my plugin.

Sometimes I’ll use the VSCode terminal for building. I stopped using the internal build/debug/run, but it’s certainly possible to set that up.

like people are saying, a lot of us do what I do. Use VCS as an editor, don’t customize anything. Run two msys2 terminals, one for my plugin, one for VCV. Re-run VCV Rack a bunch of times. It’s not really a big deal.

1 Like

Not sure if Im understanding it. Why you need a terminal for VCV? I understand you just have to iterate in your plugin, not in the vcv rack main standalone, right?

1 Like

Thanks for your tips, guys, you are being super helpful and kind here

I’m also running Rack from source, but I do keep everything within VS code: I configured it so that I have an MSYS terminal within VS code, I set up a gdb launch config for starting up Rack with the “-d” flag (so that I can actually step through the code if I need to check what’s going on step-by-step), and since I’m also using Google Test/Mock for unit tests, I’ve also integrated them into the VS Code UI using the C++ TestMate plugin (which took a lot of fiddling around until I got it to work correctly).

It still requires a ‘build dist’ or ‘build test’ to be done in the MSYS terminal (and close & restart Rack each time I changed something), but I don’t have to leave VS Code anymore to do any of that.

I do a ‘make install’ every now and again to make sure everything also still works with an actual VCV Rack installation (e.g. I had an issue once where some API I was using behaved slightly different between the official 2.5.2 Rack build and the 2.6.0 from-source build that I had set up, resulting in a crash when closing VCV Rack), or if I want to test my module with some other modules since I only have a limited set of modules in my from-source Rack (mainly Fundamental, Bogaudio, Impromptu & Count Modula)

As per the rack docs, if you want to, you can build rack from source:

But, as you are just starting out, you really don’t need to do this. My tutorial doesn’t have this step, so you only need the terminal to run make commands for your plugin.

Once you have made some progressing coding a module, then you might want to build Rack, though I don’t do this, haven’t really had the need…

yeah, like @dan.tilley says, some build and run vcv itself in a second terminal. I do this, as do many devs, mostly out of habit. so I build my modules in one terminal, then run/debug VCV in the second terminal.