I’ve been coding, building, and debugging in VS Code on Windows as long as I’ve been coding for Rack, and I got started with that guide. I do recommend understanding how to build via the MinGW terminal first, but I think VS Code is great. For me its been huge in helping me dive into the Rack source code quickly (via intellisense tooltips or right-clicking the name of any class that comes from the rack namespace). I also keep copies of the Fundamental and Audible Instruments plugin sources in my workspace so that I can search them (along with the Core modules) for quick API usage examples. The debugging works well, as long as you don’t try to set a breakpoint on the UI thread; I’ve never gotten that to work.
I think I remember that at some point I had a need to tweak something in a VS Code config file, IIRC related to absolute vs relative paths, but I can’t remember what it was exactly. FWIW here are my current configuration files:
c_cpp_properties.json (695 Bytes)
launch.json (1.6 KB)
tasks.json (1.5 KB)
Something to be aware of regarding the method in that guide and my files here, is that the building is done via reference to the Rack SDK (or a Rack source dir) while the debugging is done by attaching gdb to a full (user) installation of Rack (i.e C:/Program Files/VCV/…). This means that you need to be sure to keep both the SDK and Rack installation up-to-date separately, and your debugging environment will be the same as your everyday Rack environment with the same plugin directory (which may or may not be what is desired).
The configuration could be tweaked to instead both build and debug via a copy of Rack built from source, which would simplify maintenance and provide for separation between development & release Rack environments.