Status Update – Matt (03/09/2019)

The first action item for this week was to work on the design document, which we submitted Monday afternoon. This was really a team effort–the three of us got together for several hours on Sunday to work on the document as well as go over the feedback from our design presentation. I think that this was a very helpful step, which allowed us to get on the same page about the vision we had for the project and what steps we were going to take to get there.

One thing in particular that we had to dive deeply into was our testing procedure, as there were still several unanswered questions on that front, which were pointed out in the design review. The main question we face is how to determine if our pedal simulator is truly accurate. After some careful thought, we devised a testing plan based on a metric called normalized cross correlation, which can be used to measure the similarity between two signals. Our original hope was that we could simply use a physical guitar pedal as a reference model, and compute the normalized cross correlation between the signal coming out of that pedal and our simulated pedal. This left unanswered several questions, such as how do we ensure that the input signal is consistent for the simulated pedal and the reference pedal? How do we account for phase differences that can occur due to measurement timing? We ultimately revised our naive testing procedure to use an audio splitter to derive the reference and test signal from the same source. To account for phase differences, we will take the normalized cross correlation between our reference and test signals at a variety of phase offsets, treating the maximum correlation as the “score” in our testing procedure. I think that it was particularly valuable to work out how the testing will work for me, since I am primarily working on the pedal circuit simulator.

This brings me to the other work I got done this week. At this point, the simulator seems to be able to handle all types of resistor configurations, as well as some nonlinear components such as inductors and capacitors. I think that some further unit testing will be required before I am ready to declare this phase of the project a success, and I will be working on this near the end of spring break. However, I am very satisfied with my progress this week as it relates to the capabilities of the circuit simulator.

As far as next steps and my schedule moving forward, testing is going to be a really big deal in the next week or so. I’m hoping to build up a suite of circuits that have well known behavior, such as RLC filters, so I can perform basic sanity checks to tell whether my simulator is producing sensible results. I also hope to add models for other nonlinear components such as diodes and MOSFET transistors, which we hope to be able to support in our final product. However, testing the existing infrastructure is going to be my priority, rather than adding support for new component types, until I am satisfied with the simulation accuracy for the components already implemented.

Since circuit simulation is uncharted territory for me, I’ve been working in Python for now so that I can get comfortable with the algorithms and techniques in a language that allows me to iterate rapidly, make changes on the fly, and reason about the code without worrying about low level details. However, I also know that eventually this simulator needs to be fast. At some point in the next two weeks, I would like to start porting over some of my successful experiments to C++, which should result in better and more predictable performance.

Overall, I’d say I’m pretty on schedule based on what we submitted as out team schedule in the design document. I also have a lot of free time over spring break once I get back to Pittsburgh on Thursday, so I should have an opportunity to keep pushing forward this week.

Status Update – Stephen (03/09/2019)

This week, I spent time working on the design report and on my electron application.

This last Sunday afternoon, My teammates and I found an empty table in Gates and hunkered down to write our design report. The design report probably the biggest overarching document that we have worked on this semester for capstone. As such, it required us to finally fully flesh out any last questions we had about our project.

The first thing we did was go over our presentation feedback from the week before. It was helpful and informative to be critiqued before we wrote this design report, but since the feedback was released late in the week we unfortunately did not have time to meet with our advisors. Even so, we had a discussion about our feedback, and finally nailed down in detail the ins and outs of our testing mechanics. This is one of the sections that I think we have been hand waving the most since the beginning, so it was nice to finally have that settled.

Writing the report took much longer than I expected. What was scheduled to be an afternoon work session ended up being a whole day commitment. We divided up the report into sections and then reviewed each other’s drafts to make sure we were all on the same page.

The next morning, after our capstone discussion about the Pentium Chronicles, we did a final review pass of our design report. After another hour, we finally submitted our report.

After discussing with Sullivan, we also finalized our parts order. Luckily for us, Sullivan had a bunch of cables and a guitar that we could use. We submitted a first order for some pedals and some other small items.

The rest of my time was spent on working on my election application. I spent some more time looking up documentation and tutorials for different electron development practices. There are a lot of “boiler plates” that we can use that opens the door up for specific development stacks (different boiler plates helped users set up React, Angular, and Vue, among other things). I took a look at some of those found at electronforge.io and continued working on the app.

Next week is Spring Break! Unfortunately, I do feel like I need to make significant progress this week to stay on track. So, I plan on spending an afternoon in Cancun working, as well as working when I get back to CMU on Friday.

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 – Stephen (03/02/2019)

This week, we had the opportunity to listen to our classmate’s design presentation. It was really cool to see where everyone was taking their project, but this also meant we had to prepare for our presentation as well. In the beginning of this week, I helped Matt prepare for his presentation. We ran through it a couple times and worked out any rough edges. We also had our TA Chris go over our slides and give us his feedback.

 

We also started to talk about our design report. A lot of this discussion ultimately came from reviewing our slides and thinking about the critical questions of our project.

 

On the development side, I continued to work on our Electron application. I did some research on how Electron applications are organized and attempted to implement their file structure. I also looked into building our scrollable canvas. The idea is to have two sets of coordinates per point: one coordinate is relative to the screen that the user can see while the other coordinate is relative to the (0, 0) position on the overall canvas. Changing the displayed screen is basically transforming our coordinates from one to the other.

 

Overall, I don’t think I got as much development as I planned to. Last week, I did not anticipate the presentation and design report to take so much time out of my week. So, currently I feel a bit behind schedule. Because next week is our last week before spring break, I think it’s extremely important to make significant progress. I am leaving for spring break vacation next Friday, so I will try to frontload my work earlier in the week.

 

Next week, I hope to have the scrollable grid implemented in our desktop application. This will require me to finalize our file structure for the application. I will also need to learn more about interactivity with javascript applications.

Status Update – Team (03/02/2019)

This week, we spent the majority of our group meeting time working on the design review, particularly rehearsing for the presentation. We’ve also spent some time looking over the feedback from our design review, and discussing how this could impact what we submit for the design proposal document this Monday. In particular, we’ve identified from our feedback the need to lock down a more concrete, well-researched testing plan. This is something that we plan to research on Sunday during our group meeting and incorporate into our design document.

Besides these small group items, the majority of the work we’ve been doing has been on our own independent parts. Matt is currently working on the circuit simulator, Stephen is working on the frontend, and Joseph is working on the audio processor. This week, we unfortunately had to commit an unusually large amount of our time to the design review as well as midterm exams for other classes. This is something we think will be an abnormal occurrence, and we should be able to get back to normal this week, as we make a final push to get a lot done before spring break. We recognize that we are a bit behind our planned schedule, which is why we hope to be able to get back on track this week by putting more hours into our project than normal across the board. The fact that we don’t have any deliverables due for some time after our design document will also surely help.

Updated schedule:

The schedule contained in our design review slides was constructed relatively recently, and should still be up-to-date. Within some of the larger goals listed on our schedule, we are hoping to accomplish some of the following tasks in the near future (this week):

  • Minimum working UI
  • Audio processor capable of handling audio signals of the format provided by circuit simulator directing output speakers
  • Circuit simulator works for simple circuits (<7-8 components, voltage source connected directly to ground)

Status Update – Matt (03/02/2019)

This week was primarily dedicated to our design review. As the presenter for our team, I spent a large chunk of my time rehearsing and refining our material before Wednesday’s public presentation. In the presentation, I covered the basic design for our system, testing plans, and our schedule for the rest of the semester. The slides for our presentation can be found in this post.

Aside from the design review, I have spent a couple hours working on the circuit simulator as well. I have still been having trouble getting an accurate simulation to work with nonlinear components, so quite a bit of my time has been spent researching the best ways to do this. In particular, I have been reading through the documentation and source code for SPICE (this website offers some nice guides) in order to see what I could emulate feasibly in my own simulator. I have also produced a small amount more code (on the basic-component-simulator) branch in my repository, which was shared in last week’s post. However, I still do not have a working demo to show involving nonlinear components, which I really was hoping to have by now.

I’m starting to worry that I may be falling a  bit behind schedule, which is why I hope to dedicate ~20 hours to the circuit simulator this week. This, combined with the fact that there are no other major capstone deliverables this week, should hopefully enable me to finally break through this barrier. I think this would leave me in a comfortable place heading into spring break. This past week, I’ve had to deal with several midterm exams (both as a student and a TA), which have occupied 30+ hours of my time, between studying, writing questions, proctoring, and grading. I actually have no more exams to deal with until finals, so this should be another factor that enables me to get more done going forward. I also plan to stay in Pittsburgh for the majority of spring break, which should give me some extra time to get ahead.

By next week, I’m hoping to be able to test out basic filters and pedals. I don’t expect that they will be perfectly accurate, but I should at least be able to get a waveform in and see a waveform out on the other side. If I can’t get this delivered by next week despite good effort, I think it will be time to reconsider our approach to circuit simulation and perhaps consider some alternatives just in case things don’t work out as intended. For now I’m going to spend one more week focusing on getting things to work before jumping to any extremes.

Status Update – Stephen He (02/23/2019)

Stephen:

There was a lot to do this week! I spent my time divided between designing our application with Figma, building our frontend with Electron, and preparing for the presentation.

Designing with Figma:

This is actually my first time designing anything! Although I have done some front end web development before, I have always worked with a designer who provided the assets and design of the product. From this experience, I’ve definitely grown more appreciative of the hard work they do!

There are a lot of design tools out there, but I settled on using Figma to help organize what our application will look like. Figma is an online UI design tool that allows for teams to work together without needing to pass around a messy amount of assets and images.

Although Figma was really helpful for our team, there definitely was an initial learning curve to using Figma. The application is really powerful and lets you do so many transformations to an image, for instance. However, the abundance of tools made even the simplest thing a bit contrived to do.

After a little trial and error, I came up with this design: 

 

Building with Electron:

Building with Electron seems to be pretty straightforward because I can mainly proceed with Node.js development. However, scoping and testing things out this week definitely made me more aware of how many moving parts there are in the frontend. For example, to be most effective, the circuit simulator would ideally be able to snap circuit components together, allow the user to expand the canvas / scroll around to build large multi-screen circuits, and creatively organize wires with labels to make the circuit readable. The main takeaway from messing around with Electron this week is that I need to increase my pace of development of the frontend for this semester.

I began this week by making a simple “Hello World” application. I moved on to messing with some features such as a file manager and adding custom HTML.

 

This week, I hope to have a v1 of our application built and ready. I want to be able to click through circuit parts and move them onto my grid to build a circuit. I’ll save converting the circuit to a netlist for a later time.

With my current progress, I think that I am on track / a bit behind. I want to push a bit more on the front end progress before spring break, so for these next two weeks I’ll invest more time than before.

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.

Status Update – Team (02/23/2019)

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: