Today it’s time to talk about debugging with Xcode 2.4. And be warned, debugging can be a pain with Xcode. But first things first.

You choose the VST host in Xcode with “New Custom Executable”. You can add as many as you like, not like Visual Studio where you can only set one.

With Xcode 2.4 a new debug information format called DWARF was added to the existing stabs format. With this change it’s actually possible to debug C++ code. But the default format is still stabs, so go into the target build settings and change stabs to DWARF.

So when you now hit “Build and Restart” your preferred VST host should start.

Now to the caveats. GDB or Xcode has a bug that when your vst was once loaded and then unloaded and loaded again all your breakpoints wouldn’t break. This is a problem in hosts like Cubase which scans all modified or new plug-ins on startup. So if you need to use Cubase as host, start it first without debugger let the scanning happen and then quit Cubase. Now you can hit Debug to actually debug your plug-in.

If you have objects like the VstTimeInfo and you want to see a summary of its values in the debugger Xcode has some nice method: double click into the summary field for the variable (in this case the VstTimeInfo variable) and enter Tempo: {$VAR.tempo} bpmNow you see “Tempo: 120 bpm” whenever a VstTimeInfo struct is in the current scope (and the tempo is 120). Because of some bugs in Xcode or gdb this does not work everytime.
You can even call methods of that object (if it has methods, VstTimeInfo does not have any method). Just take your effect class (AudioEffect) and enter Sample Rate: {$VAR->getSampleRate()}into the summary field and you will see the current sample rate whenever your effect class is in scope.