To test your module with the debugger, choose the “Debug” option from the “Build” menu. The module designer will build your module and, assuming no compile errors, launch a child process with a cabinet containing your module and the Test Signals module:
The Test Signals Module contains a variety of inputs and outputs to help you test your module. It includes five sections, from top to bottom:
From Host: A variety of CV and MIDI inputs from the MIDI devices you’ve chosen in the module designer’s Preferences dialog.
File Playback: If you specify the “File” option from the Sound Source section (just below this one), you can use this section to load an audio file (MP3, WAV, OGG, FLAC, or AIFF) and use it as a sound source for processing in your module.
Sound Source: This lets you choose an audio source for sending to the module via the “Test Signal Outputs” section below. You can use a square wave, a sine wave, an audio file, or an external input such as a microphone (see the module designer’s Preferences dialog for available inputs). If you select the sine or square waves, the “Osc Freq” knob sets the waveform’s frequency.
Test Signal Outputs: This section contains mono and stereo output jacks for sending your chosen sound source to your module.
Audio Ret To Host: Hook the output from your module back to these input jacks; they’ll get routed to the audio outputs (your speakers, probably) specified in the module designer’s Preferences dialog.
The Child Process’s Menu
The menu in the debugger child process lets you test your module’s undo/redo capabilities (via the “Edit” menu) and how it looks at varying zoom levels (via the “View” menu). The “Add Modules” menu allows you to add other Voltage modules to your test cabinet:
The Module Designer will remember your cable connections, extra modules, and control settings from session to session. If you need to clear them, select the “Clear Test/Debug Mode Settings” option from the module designer’s “Build” menu.
Note that if you hit a breakpoint or otherwise pause debug execution, it’ll halt execution of the entire debugger child process, including the interface thread, so the Edit/View/Add Modules menus won’t be accessible when execution is paused.
When the debugger launches, the title bar for the output pane (the pane at the bottom of the module designer in the default setup) will sprout a series of tabs along its left edge:
and a row of buttons along the right:
When execution of your module has paused due to hitting a breakpoint, pausing, etc., the buttons allow you to resume execution in various ways:
resume: resumes execution unconditionally, either until another breakpoint is hit or you pause execution via the “Pause” option on the Debug menu.
step in: If the line of code where execution is paused includes a function call, step into the function. If it doesn’t, skip to the next line of code.
step over: execute the current line of code without stepping into any function calls it contains
step out: execute code until execution has exited the current function.
The Row of Tabs:
The “Output” tab shows the normal contents of the Output pane, including the results of any Log statements in your code:
“Oscillator”: This tab will be labeled with your module’s variable name and will show the values of all the variables in your module:
The first column shows variable names, the second column their values, and the third column their types. Most non-primitive types will have empty value columns; click the little expansion arrows to the left of their names to show all their child members, which will have filled-in value columns if they’re not themselves complex types.
The “Locals” tab has the same layout as the Module tab, but shows values for all the local variables at the current point of execution:
The “Threads” tab shows all the active threads and the call stacks for each, with threads in the left column and the selected thread’s call stack, if available, in the right column:
Click on a stack frame and then switch to the Locals tab to see local values for that stack frame, if any are available.
The Module, Locals, and Threads tabs will be disabled unless debug execution is paused.
Breakpoints: To set a breakpoint at a particular line of code, either click in the line’s left margin, right-click and select the “Toggle Breakpoint” option, or click the toggle-breakpoint hotkey (F9 on Windows, Command-Backslash on Mac). A red circle will appear in the left margin to indicate that the line has a breakpoint:
Use the same process to remove breakpoints. There’s also a “Remove All Breakpoints” option on the Debug menu.
When execution stops at a breakpoint, the line will be highlighted in the code editor and a yellow arrow will appear in the margin: