Status Update – Joseph (05/04/2019)

This week we focused primarily on finishing our final presentation, as well as the poster for our demo session. For the final presentation, I worked on adding information regarding to the final outcome of our project with Stephen and Matt. I also had to change the diagrams and details for the audio processor module, since a lot of it had changed since our design proposal.  We also worked on poster and submitted it to be printed as a team.

For the upcoming week, our main primary focus is to finish our project report. We will also be preparing for the demo on Monday, making sure that our project works as intended on the day of.

Status Update – Joseph (04/27/19)

This week, I spent a good amount of time working on our final presentation slides with my teammates. There were a good number of changes to especially the audio processor than was originally planned, so I had to reconfigure the diagrams and what not. In addition, i worked on adding an amplify or boost effect so that we would be able to observe the clipping from the diodes we implemented.

In the coming week, i will work on the poster, as well as preparing for our final demo.  Continue reading “Status Update – Joseph (04/27/19)”

Status Update – Joseph Kim (04/20/2019)

The past week, I finished up the live aspects of the simulator and implemented a few digital effects. The digital effects include delay, reverb, distortion and fuzz. I worked with Stephen and Matt so that the frontend can now support chaining digital effects with the actual circuit. The digital effects were all implemented under the same virtual class, and the latencies from all the effects are fairly low. The digital effects also sound fairly convincing. I ran into a problem at one point where the audio would sound very distorted unless I set the input latency very high, and this problem was also apparent on audacity, but we found that this was solved by rerouting the output to the audio interface rather than playing it out through the speakers of the computer. But by rerouting the output to the audio interface and then to an amp, we found that we we could achieve fairly low latency. At this point, our project is coming close to our final product and ready for the demo.

In the upcoming week, I want to work on polishing up the code and testing it. I also am planning to refine the reverb and distortion effects, as they are both a little bit less sophisticated than I would like. I will also work on making the effects take in variable parameters. I will also be working on our final presentation and preparing for the demo.

 

Status Update – Joseph (04/06/19)

This week, I spent a good number of hours integrating parts together. I also restructured a lot of my code so that it would fit in better with Matt’s backend components. I worked with Matt and Stephen to finalize what we were looking to have by the demo and worked on finishing it. I also spent some time integrating the live audio, though I haven’t had time to test it as I was busy in the second part of this week with other things.

Moving on, we decided that we also wanted to have some digital effects as part of our code, so I’ll also be working on that. These effects may include clipping for distortion, echo, and more. I also need to work on the live audio, and I imagine spending a good amount of time tweaking parameters, like the size of each buffer or the number of buffers to store, or the actual implementation to get the results we want.

By next week, I hope to have a good amount of things I mentioned done, though with Carnival my progress may be stinted a little bit.

Status Report – Joseph (03/30/2019)

This week, I worked together with Matt to make it possible to send either microphone input or file input to the circuit simulator, then have it play out in the speakers. This was written for the preliminary simulator written in Python, so we’ll have to make some adjustments when the simulator is ported to C++, but the core part of the input/output processing is done.

Though the initial plan was to help out with the circuit simulator afterwards, we decided that it would be more efficient for me to start working on the testing platform instead. So, I’ve made a tool to visualize input and output audio samples in both the time and frequency domains, and am working on adding the cross correlation test to it.

I want to continue working on the testing framework and have the core of it done by the midpoint demo so we can showcase our work. Afterwards, I can add features that make it easier to test like automatically running our results against SPICE’s.

We also ordered and received the new audio interface, which supports two inputs. Using that, I’ll also be working on getting both the clean sounds and distorted sounds from the same guitar at once.

Status Update – Joseph (03/23/19)

This week, I worked on a few things. Our parts arrived for the pedal we are testing against, so I spent a few hours assembling it. It took longer than I initially thought, since the circuit is fairly simple, but having to solder in a small confined space with a rusty soldering iron proved more difficult than I initially thought (I had to get another soldering iron eventually). Once the pedal was built, I tested it with a guitar to make sure it was working as intended.

I also spent considerable amount of time trying to figure out how our audio processor built on JUCE was to be integrated with the rest of our application. While JUCE made it really easy to get started and was well documented, it was difficult to get out of the environment it sets up. I spent many hours trying to get the build to work with a Makefile rather than on XCode. Though JUCE also gives users the ability to generate a CMake, it was only compatible on linux systems and not on OS X, our main target platform. I looked into an open source code named FRUT that claimed to do what I wanted, but that didn’t compile successfully either.

Considering the fact that our Audio processor is much simpler than we initially imagined it to be, we decided that the JUCE library was a lot more heavyweight than it needed to be. So, after a bit of research, I decided to switch over our platform to use Portaudio for audio I/O and Libsndfile to read audio files. These solutions are way more lightweight, requiring me to only put in two linker flags to compile. The only downside is that the documentation is way more limited — the C++ wrapper for Libsndfile didn’t have any written documentation at all, so I just had to read source code and header files to figure out what they did.

Most of the functionality of the audio processor is done now, so next week, I want to focus on our testing pipeline. I need to figure out how to split the audio signal from the guitar/preamp, and record it on two computers. One computer will have the pedal we built connected before receiving the signal, giving us a way to get both the clean audio signal and the distorted signal. With this, we should be able to run the clean signal through the circuit simulator and compare it against the real circuit signal.

Status Update – Joseph (03/02/2019)

I spent a good portion of my time this week working on the design review with my team. In addition to putting our slides together and refining what we had from the first presentation, we also spent time with Matt to rehearse the presentation. We also discussed some elements of our design report that we would need to modify from our presentation, like the schedule.

On the developmental side of things, I definitely didn’t get as much done as I would have liked. By this week, I had planned to finish working on the audio processor and hop on to working on the simulator with Matt. However, I didn’t foresee the midterms and projects that piled up on me this week. Thus, I am hoping to spend more time next week and during spring break to catch back up. I haven’t made much progress in terms of the audio processor, but it being a fairly simple module, I’m confident I can finish it in the next few days. By next week, I plan to finish design report, the ethics presentation, and a component (i.g. A diode) that Matt hasn’t implemented yet for the circuit simulator.

I also plan to go over with the team to create a more finely granulated schedule for the weeks ahead. It’d be productive to have our tasks broken up into smaller chunks so that we can keep ourselves at pace and be on track.

Status Update – Joseph (02/23/2019)

This week, I worked on the design review, as well as continually doing research on the audio processing module. As we worked on the design review and the intrinsics of the circuit simulator, we came to realize that the circuit simulator wasn’t going to work as we had initially thought. In our original plan, the circuit simulator would find a transfer function for the circuit, and the audio processing module would use the derived transfer function to apply the effects.

I looked into JUCE’s WaveShaper module, which would have allowed me to apply various functions to incoming signals. However, after some research, we realized that most pedal circuits have non linear components that are a function of time, and that it’s difficult to produce a mathematical model of an arbitrary circuit. Thus, our approach shifted to one where the heavy loading is all done within the circuit simulator. We saw hope in this approach as some other implementations produced fairly promising results, where the processing was faster than the actual audio file (though this may vary with different files and circuits).

We then decided as a team that the audio processing module’s job would now be to load input audio and write output signals, choosing between either the 3.5mm jack or the filesystem as the input, and choosing between the speakers and the filesystem for the output. The structure of the module is shown in the following diagram, which I made using diagrammaker.com:

The JUCE library also supports communication with the computer’s audio hardware via the AudioSampleBuffer module. The interaction with the filesystem can be done with traditional UNIX syscalls.

This model of the audio processing engine is a lot simpler than we had initially conceptualized. Since much of the bulk is now in the hands of the circuit simulation engine, I’ll be shifting gears and help Matt on the circuit simulation portion once the basic structure of the audio processing engine is complete.

I think that earlier in the week, the change in plans for the audio processor caused me to go down certain rabbit holes that are no longer relevant. This caused some lagging in terms of progress, but I think we now have a much more solid foundation as to what our project is going to be. Moving forward, I hope to have the audio processing module done by next week and get ramped up on the circuit simulation.