2196 posts since 17 Apr, 2005, from S.E. TN
One way I would debug if in a plugin, is to make a two-channel mono test file, same audio on left and right channels. Rather than play the file and listen, I would render the test file to disk thru the plugin, only modifying for instance the right audio channel. Then the stereo audio rendered file can be opened in a stereo editor with the original audio in left channel, and the changed audio in right channel, so the differences can be micro-examined and compared.
The same could be done, looking at the output file in the DAW audio display window, if the DAW audio display window is good enough. I don't have every modern DAW. Maybe some of them have wonderfully accurate audio display windows. I like reaper for sequencing but for debugging fine details in the waveform display cooledit pro/adobe audition is better to me. If you have a DAW with an absolutely wonderful wave display window then you don't need the extra step of examining results in a stereo editor program.
Along the same lines, your plugin during dev/debug doesn't have to output audio. You could process the dual-mono file as above, with no change to the left channel, but print the envelope output to the right channel rather than audio, and look at the results in an audio editor. If you play a file with the envelope written into a track it would sound awful or at least useless, but a good audio editor will DISPLAY the behavior of the envelope in response to the audio, so you can see the source audio in the left (top) wave display and see the resultant envelope in the right (bottom) wave display, to help see and figure out what is working right vs what is working wrong.
Until fairly well-along with a plugin, my test files would probably be variations of simple sine wave signals or other geometric waves, not "real music". The real music is only tested after the plugin seems to be dealing correctly with simple signals. For instance a compressor test file might be various durations and levels of sine wave (at various sine frequency). Maybe 1 second of -18 dB sine wave then 100 ms step of 0 dB sine wave, returning to another 1 second of -18 dB sine wave or whatever you think you need to test.
And as stratum said, if stepping thru the code is necessary to find problems, putting the code into a shell that reads the test file off disk and writes the results back to disk makes it lots easier to debug some things. In the past I had a little command line shell that would read file input and file output name lines from a text file, along with whatever parms I might want to change via text file. It could have been made fancier, but given the basic code shell that would read the simple control file, open the input/output files, read from input file, convert to float, an empty process routine, then covert from float and write to the output file-- I could just make copies of that simple small program source code and paste in different "process code" in-between the file-read and file-write, whatever I needed to test.
It sometimes seemed good for rough code efficiency timing as well-- For instance if it takes the program 2.1 seconds to simply read/write the file doing nothing else, then any time over and above that 2.1 seconds is the overhead required by whatever code I insert into the processing function.