Attaching Debugger to VCV

I’m curious if people use a debugger when developing for rack, and if so how you attach one. I’m on win10 and I’ve just been using make install from the command line.

‘make debug’ and then start that build under your debugger?

1 Like

What debugger do you use? Right now I’m just using sublime for a text editor. Are you using Visual Studio or something else?

make debug launches gdb on winodows and Linux. On mac it launches the lldb. so regular old debugger with command line is what you get. No fuss, no muss. Some ppl set up gui front ends like Visual Studio Code, I think. But the command line one is the “no thinking required” option.


So when I run make debug I get make: *** No rule to make target 'debug'. Stop. I suspect that is because I’m running the make file for the plugin not VCV Rack itself? And if so, is there a way to debug VCV rack without building it yourself?

oh, right. Yeah, that’s the vcv makefile. I always make VCV and make plugins under it. But all make debug does is: gdb --args ./Rack.exe -d. So I never attach, I always launch the exe in the debugger.

1 Like

I don’t know it there is an advantage to building VCV first - it’s what you had to do back in the dark ages. It does give you source level debugging back into VCV, which can be handy? Sometimes, also, I want to put some INFO statements in VCV so log what it’s doing…

For me, Rack is less important to self-build then the SDK. The delivered SDK is stripped and optimized which is the worst thing for debugging. Every time your code uses a SDK method or a SDK defined structure/class you end up with blank or <optimized> labels in the debugger.

but if you self build rack it IS the sdk. You then build your plugins against rack itself. So same thing.That’s what we all did “back in the day”. I don’t think there was a separate “SDK”.

1 Like

True and that’s what I end up doing. Just stating that the important part here is the debuggable SDK. The actual Rack executable is a tiny binary (at least in Linux it is).

1 Like