Posted on

Team’s Status Report 2/14

This week we met with Tom Sullivan and Daniel Zhao to discuss our plans. We decided upon the Terasic DE10 FPGA to begin synthesizing and testing our modules ASAP. Shayaan wrote a saw in Verilog, and visualized it in VCS, as detailed by his report. Jake tried something similar with a square of arbitrary duty. Daniel focused on distinguishing between host versus participant in USB I/O communications between the Waveshaper, PC interface, and MIDI controllers. Jake investigated the on-board codec to decide if it’s suitable for our purposes in live audio.

(A) One public safety concern related to our project is excessive sound exposure. Prolonged exposure to sound levels above 85 dB can cause hearing damage. Therefore, if we include headphone peripherals, it is important to ensure that the output does not exceed safe listening thresholds.

Additional safety considerations include proper power regulation, adequate electrical insulation, and thermal management. Any components that could pose even a minor hazard should be properly enclosed or isolated from the user. By prioritizing these safety measures, we aim to ensure that our digital synthesizer remains safe and accessible to all users.

(B) Musical synthesizers do really well to serve social factors, simply because music is an innately social and cultural thing. People both make music together, and go to venues expecting to hear live music. We use music to help create the cultural moment we’re living in, whether we’re playing or just listening. The Waveshaper’s minimal feature set serves on two fronts: first, the musician is forced to be intentional about the sound they’re making, as there aren’t unlimited tools, and second that this robust feature-set allows a broader set of users to access the device. A more streamlined feature-set means the portability increases, and price comes down, because the hardware isn’t bogged down supporting features not every patch will use.
Secondarily, this project serves as an educational tool. Implementing on a dev-board means that there will be verilog to share. A musician needs awareness of the control-path to make music, but it might be useful for an engineer to see a device that is so explicitly tied up with the concept of inter-connected modules. The musical synthesizer is a very externally visible implementation of very ubiquitous design concepts in hardware. This visibility of path makes it a great educational tool perhaps for extendability.

(C) From the get-go, the WaveShaper was set out to meet particular cost criteria. As a project targeting hobbyists and experimentalists, keeping a low economic barrier to entry was a priority in the design process. This goal was not only considered for the choice of on-board components and associated manufacturing expenses but also in how the device would be used once in the hands of the end user. This secondary aspect is twofold. For one, by ensuring that the ports and interfaces were as generic as possible, a variety of peripherals and computing devices can be used. This opens the door to the use of secondhand markets and even so-called “libraries of things” to customize the user experience. Moreover, we aim to leverage the use of an FPGA and its dedicated sound synthesis as an accessibility feature. To achieve the same real-time performance on a general-purpose computing device in software would be much more expensive and would compete with possibly limited compute and I/O bandwidth for graphics, web tutorials, etc. A less powerful desktop PC, laptop, or even a single-board computer like a Raspberry Pi could be used as the interfacing device.

Part A was written by Shayaan Ghandi. Part B was written by Jake Tarin. Part C was written by Daniel Abujaber.

 

Posted on

Jake’s Status Report for 2/7

This week I prepared for and presented our Project Proposal!

Whilst Shayaan spent time determining which FPGA we should use, and Daniel focused on how we should implement MIDI, I spent my time figuring out what additional hardware may be necessary for the synthesizer. This coming week, I am to decide how the output after the FX channel should convert into L/R stereo ¼” outputs, as well as a driven 3.5mm headphone jack.

The precursory control-path we’ve devised has some details which will dictate the external hardware required. Take for instance, the implementation of our oscillators. We could have a control-path to generate the desired output oscillation, for instance, a sawtooth generated by an accumulator register, and adder. In contrast, synthesizers have also been designed which read pre-computed samples of a waveform from a read-only memory. Each choice enables different advantages. For instance, an “oscillator” reading out samples from memory would allow for the implementation of a “user-bank” where users could send their own arbitrary waveforms to be read-out in playback. However, basic saw, sine, square, triangle function oscillators would suffer from the regularity of the access. Some argue that the use of precomputed values changes the character of the synthesis because you’re getting the exact same value every single time. Yet a wavetable implementation would require such a memory. We will likely move forward with oscillators dedicated to each style: preserving the character of basic function oscillations in a subtractive synthesis, and using memory-indexing “oscillators” to support user-defined waveform readout.

The cost of supporting memory-indexed “oscillation”  is offset by the fact we may use the memory for other things too. Among the effects we’ve elected to implement are chorus and delay, which will likely require discrete memory to push parameters like max delay time, without compromising upon our generating sample rate or sample bit-depth. Certain filtration techniques use sliding-window algorithms, which may also benefit from expanded memory capacity. If we somehow managed to skate by without discrete memory for implementing any one of these oscillators or effects, using them in parallel would likely create issues anyway. To this end, one of us will decide which specific memory shall be used when we decide upon an FPGA dev-board. 

Now a little about taking the end of the synthesizer’s control path, and forming it into an audio output. Once we have a digital signal ready for output, we need to get the signal analog so that an amp or speaker or transducer-of-your-choice can take it as input. There are a lot of dedicated ICs available from manufacturers to assist in this task: my chief consideration at this time is an audio-codec from Texas Instruments. We’d ensure our output is a well-formed I2S data-stream (a different protocol than I2C, despite the similar name), drive power to chip, and have ready-to-go output for a speaker or pair of headphones. I am unsure whether this will be suitable for a ¼”  line out however, any circuitry required for our audio output I’ll have figured out by the end of the coming week.

The TI slide-deck I’m looking at as I consider audio-codecs is available  here.