Jake’s Status Report 4/4

This week was the WaveShaper interim demo. In trying to bring up the envelope onto the FPGA, I encountered unexpected issues with noise. The envelope successfully modulated the volume of the oscillator, moving through each respective phase, but something about the multiplication to scale the output is off. I tried things like synchronizing the inputs, or changing which clock modules made use of, I tried synchronizing the oscillator and envelope to only advance when the I2S ip-block moved to the left-sample-ready, sending zeros on the right. I tried explicitly setting a clock frequency on the FPGA, or driving the modules at 50Hz, with an added enable line to update the output samples in-respect to the audio-clock rate. Shayaan figured out that samples sent to the IP-blocks should actually be offset-K, which I intend to synthesize ASAP. The oscillators I was testing with were unsigned, and initially sounded better than did signed implementations. I also tried various things with the multiplication, such as “pipelining” it, in case it were somehow that  samples were  being dropped. What was working best was simply casting values to signed, but explicitly converting to offset-K is the correct behavior.

This week we also ordered the MIDI controller for use in the final demo. Users will be able to send at-once four voices. Arbitration will hold 4 voices in play, but drop a key in release if a new one is pressed. I chose the NEKTAR IMPACT LX49 for the controller explicitly to make Daniel’s life easier with the MIDI-CC features. It has 8 dials, and 9 sliders with a bank. The bank is desirable because the keyboard will manage a “page-toggle” control feature without us having to handle arbitration on the limited FPGA fabric. If we have more user-tunable parameters than are dials on the keyboard, this internal bank will allow the user to shift through the set of parameters the hardware buttons control, and the keyboard will do this for us by sending different MIDI identifiers.

Verification here is more than technical, as a lot of the tuning of parameters need to make sense from a user’s perspective. The first step in verification is through inspection through VCS. A more rigorous verification will involve comparing this sample-by-sample to the MATLAB pipeline equivalent, but should be functionally the same. The MATLAB comparison will become especially important as we test the effects, and summed waveforms. The MATLAB comparisons will also be important as we combine elements, as we should get the same stream out, bit-by-bit if the same elements are staged the same way. The last piece is the subjective, focusing on my own parts, the part to be verified is the playability. The last piece isn’t rigorous so much as: “are the options presented meaningful?”. When the WaveShapers various parts are all finally assembled, “Can I forget the instrument is there and just play?”.

Leave a Reply

Your email address will not be published. Required fields are marked *