Debugging Tools - Updated


#1

I've tidied up and updated the debugging tools here:

https://github.com/jcredland/juce-toys

I was slightly embarrased by the sloppiness of the code, and as a one-time-only change I've also renamed two of the classes so it's a neater: 

ComponentDebugger, ValueTreeDebugger and BufferDebugger.

I've also included:

  • Natvis script for decoding JUCE objects in Visual Studio (I may have mentioned this one already).
  • A new LLDB script for decoding JUCE objects in Xcode (Array, String, ValueTree etc.)

If you don't have something equivalent I think these are pretty much essential for problem solving, give them a go.  And the LLDB script I think is more reliable than the current sticky suggestion on how to configure the debugger to show strings.

There's also a demo app showing the ValueTreeDebugger and ComponentDebugger in action.  I don't know how best to make it build out of the box without including all the JUCE code as well.  So you'll need to configure the module paths to run it.  Is there a good way of handling this?

I'll add the BufferDebugger to the demo app when I get a moment or two spare.

Feedback good or bad gratefully received. 


#2

grabbing them now.  i'm quite embarrassed to admit i still debug by std::cout :p


#3

There's nothing wrong with std::cout ;)


#4

stdout is cool - but sometimes it's just not quite enough :) 

Though LLDB has given up on me with my toy project.  Does anyone have any ideas about this:

http://stackoverflow.com/questions/33914208/lldb-is-not-setting-breakpoints-at-the-correct-line

 

 


#5

Thanks @jimc, the BufferDebugger (trying saying that after a few) is helping me debug some tricky click issues in the looping app I’m working on. Looping’s easy when your loop length is a multiple of your buffer size… keeping track of loop & buffer boundaries with sample accurate loop points is harder than I thought…!

Some thoughts: Would be cool to have this as a separate app, that used an Interprocess Connection or shared memory to be able to inspect the audio buffer while stepping through the debugger. Actually I guess each step could use a different capture which you could then look at afterwards… anyway, nice work :sunglasses: