This Sunday, the team finalized a functional interim-demo of the WaveShaper that involved end-to-end I/O functionality, oscillators, mixing, and integration with each feature’s component except for the MIDI keyboard which should be on the way soon.
Shayaan worked on the RTL for SVF filters, also wrestling with the binary-offset encoding confusion in our IP-blocks. Jake worked on the synthesis of the ADSR envelope, ordering a keyboard, and the beginnings of the RTL for effects. Daniel successfully brought up MIDI parsing and system integration. His work result was a demonstration that could take a MIDI file from a host-machine, and play it back with saw-tooth oscillators, whilst showing the youngest notes requisite MIDI information on the DE-10’s seven-segment display in hex.
With the core elements of the subtraction synthesis pipeline at or near completion, what remains is the synthesis of filters, and adding of effects. This will transform the WaveShaper from a set of disconnected digital signal tools to a real interactive instrument.
There were a few setbacks encountered in unifying the pieces which we’re in the process of resolving. Not all components have been modified to support the binary-offset which the DAC requests in producing the output audio stream.
As the final product takes its shape, now is the time to consider both modular and integration tests. Diagnosing issues in each sub-system is much easier when direct focus is applied, and integration often comes with its own difficulties.
There are generally three types of bugs that we will be looking for in the Waveshaper hardware:
- Logical. (A fundamental flaw or oversight in the HDL algorithms and circuit designs which break the desired properties. Example: an error-prone frequency modulation algorithm which drifts non-linearly or jumps suddenly.)
- Implementation. (An issue in communication between components or hardware bottlenecks breaking system correctness or decreasing system performance. Example: A propagation delay in a MIDI stream reading system which results in lost bytes.)
- Subjective. (Something which breaks user expectations or lacks musicality despite technical correctness. Example: two frequencies within a reasonable margin of error of the target but sounding dissonant together due to a mismatch in their ratio.)
(Logic and Implementation may be ambiguous categories. Generally speaking, logic errors are discrepancies between the underlying mathematical functions which drive sound synthesis and the HDL specification. Implementation errors are hardware engineering oversights or mistakes which cause lack of coordination between the components as synthesized. An out-of-spec driver is considered an Implementation error.)
Logical errors for internal components will be caught and addressed by using HDL testbenches for simulation. The oscillators, ADSR envelopes, filters, and FX can all be implemented in MATLAB to provide a reference series of values in a controlled environment. MATLAB references are faster to implement at the cost of being slower to execute than the synthesized logic on an FPGA.
Logic errors for components may also be tested against pre-existing tools. For instance, the Linux command line utility amidi which comes with many distributions of ALSA (a long-standing backend for Linux audio) can be used to compare the parsing of our custom MIDI receiver with a battle-tested one.
Implementation errors will be diagnosed through measurement. There are oscilloscopes in the engineering labs which can measure the frequency of periodic signals and provide ratios between the peek-to-peek range in a signal with a (non-degenerate) envelope and its maximum. Such tests have already been fruitful in finding hardware artifacts in attempting to drive the speaker with discontinuous waves which can be eliminated with imperceptible interpolating stages.
Finally, subjective errors will be suggested by end users attempting to use the WaveShaper. These will be deliberated on, and minor changes to the specifications may be implemented.
Pitch and interval correctness, rhythmic consistency and responsiveness, lack of artifacts, and waveform consistency are all technical factors which can be tested using an oscilloscope at the audio output. Ease-of-use can be tested in small groups of both experienced and inexperienced users of the WaveShaper.
The software will be tested with Rust unit tests. Importantly, the core library which communicates with the WaveShaper can be tested as a list of API calls. The GUI interface software is likely too stateful to exhaustively test. As a result, in-the-field bug hunting will be done merely using the software, and an emphasis on robustness and being able to recover to states which are known to be well are critical.
