Newb - whats a good way to debug (find out what a variable contains) while a plugin is running?

I’ve been having trouble getting Visual Studio (2019) to show Output->Debug values.
My plugin doesn’t seem to want to print to this Debug window. I used DBG and juce:Logger.

I then tried to make a little textArea box in the plugin GUI, and that worked, I was able to output values there.
I know that you’re not supposed to be writing to a textarea in the ProcessBlock() because it has to run efficiently.
In fact, it was working OK, I was able to print out to this textarea what Note_On midi buffer values were coming in.
If I pressed one key at a time, it worked fine, however, if I pressed more than three keys on my midi controller, the plugin crashed.

Anyway, all that to say - whats a good way of having a window so every now and then I can see what a particular variable is holding?
I also tried Immediate window etc.

1 Like

DBG and Logger::writeToLog should work with Visual Studio, but you have to run a debug build of the plugin in the host under the debugger. (You have to set the host application as the debugging “command”.)

Note however, that DBG and Logger also shouldn’t really be used from the processBlock/audio thread code. (They will probably work for development use, but they may cause audio glitches that might confuse what issue you are actually trying to debug.)

I am not actually sure how you got your GUI text component to work? Under the debugger you should have got a jassert that the GUI component methods should not be called from non-GUI threads.

1 Like


If you are looking for a way to get some logging from the per-sample processing code without too much impact, one possible solution is to have a logging every 10000 samples or so, the following macros can help (also in debug builds):

#ifndef NDEBUG
#define X(textToWrite)                                                         \
  JUCE_BLOCK_WITH_FORCED_SEMICOLON(juce::String tempDbgBuf;                    \
                                   tempDbgBuf << textToWrite;                  \

#define X_EVERY(n, textToWrite)                                                \
  {                                                                            \
    static int i = 0;                                                          \
    if ((i % static_cast<int>(n)) == 0) {                                      \
      X(textToWrite);                                                          \
    }                                                                          \
    ++i;                                                                       \

It can be used that way:

X_EVERY(10000, "xn=" << xn << ", yn=" << yn);

It won’t help much if you have one value that screws up the signal, but to debug parameter values and get some confidence about what’s going on, I find them helpful.

1 Like

I actually tried this but the VS build gave me a write permission error. I had Reaper set up in the Command properties etc. The folder is not write protected; I can create files there manually. I’ll have to upload a screenshot of what its doing.

You need to select debug → attach to process & select your plugin from the list

1 Like

Yes, that seems to be working for me when I attach it to the Reaper process. thanks.
Setting the command in Properties > Debugging > Command path did open Reaper but did not link the Debug:Output Window to what was going on very well and seemed even to be giving me output from a previous build of the plugin.

What about writing to a log file? I know writing to files is usually a bottleneck, but I have an SSD. I might give that a try. I wonder if I can see the log time being added to in real time?