Risks
The most significant risk is still that the circuit simulator will not be fast enough to process live audio. We haven’t come far enough in our implementation yet to confront this problem directly, but we strongly believe that this could be an issue that we will face in a couple weeks. Our approach to this problem has not changed since last week. We plan to run each user-specified circuit through a preprocessing phase, where it will be simulated at a variety of operating points, in order to speed up live simulation. We also plan to allow pedal designs to be tested against recorded audio, which loosens the time constraints brought on by live simulation.
Design Changes
There was a change in the structure of our program. The audio processing module is now only responsible for loading audio inputs and writing outputs, and is not responsible for modifying the audio signal. This change was necessary as we determined that it’s not feasible to derive transfer functions for circuits whose output is dependent on the current state. Thus, the circuit simulation engine is now responsible for the audio modification. The only real loss from this change was the time we spent researching and prototyping. Moving forward, I think we have a much better understanding of how circuit simulators work and what our project will look like, which will prevent us from making big changes in the future.
We also spent a lot of time ironing out little details in our design which were not finalized last week. A good example of this is the exact signal passing protocol between the audio processor and circuit simulator. We believe that these kinds of refinements are naturally tied to next week’s design review presentation, which requires us to have thought out the small details in our design and implementation plan.
Schedule
As we’ve become more familiar with the technical challenges we face, we have naturally been able to get better estimates for how long various things will take. Here is our new projected schedule:
