Tag: status report

Jolin’s status report for 5/8/2021

  • I gave the final presentation about our project. Everything went smoothly and I am satisfied with the outcome.
  • I continued to integrate the unison detune and ADSR features into the system. I changed the algorithm for unison detune so that the changes in period for the auxiliary oscillators roughly and efficiently correspond to the even spacing in frequency. Now the unison detunes actually sounds like the effect we get from a typical linear unison detuner.
  • I am implementing the record and cycle feature. It’s expected to be completed by tomorrow.

Next week I will be helping Michelle finishing up the video and working on the final report.

Michelle’s status report for 5/8

This week, I worked on the final presentation slides, and I helped our teammate practice the final presentation. I also worked on editing the final demo video. The video is mostly done now, with a few segments still waiting for integration of our system to be completed. I will be working on the video tomorrow and Monday to make sure that our video is a clear demonstration for all of our work.

Next week, I will be finishing the video and working on the final report.

Hongrun’s Status Report for 5/8/21

This week I have mostly wrapped up my part of the project this week by implementing the bonus wavetable oscillator features:

  1. I wrote a script that converts the .raw files that Michelle generated from an open-source library to .vm formats. I used a module for taking in the .raw files as a stream of 16-bit data samples and then converted each data sample into 24-bit and storing each of them in order in a .vm file because the AUDIO_BIT_WIDTH we set for our project was 24.
  2. I changed the configuration variables in SystemVerilog so that now it would give our oscillators access to the new wavetables in addition to sqr/sin/tri. This was not that difficult because I was able to reuse a lot of the code in the sqr/sin/tri wavetable oscillator module. Our previous features such as ADSR and PWM will still work on the new wavetables.
  3. I modified the ChipInterface module to allow our users to choose waveforms from the switches on the FPGA. We would have loved to move this interface onto our keyboard, but we, unfortunately, ran out of knobs to do so.

What is left for next week is very minimal, just mostly merging my code with Jolin’s ongoing progress with the Record and Cycle functionality. I will also help with Michelle’s work on the video and our report together!

Hongrun’s Status Report on 5/1/21

This week I got a lot done and am wrapping up my personal tasks for this project in general. I did the following:

  1. Finish ADSR implementation and successfully synthesized it.
  2. After Michelle did frequency testing and found out that our system has very severe pitch deviation, I changed two things to improve the problem to a degree that is acceptable: a). increasing audio frequency rate (50kHz -> 400kHz) before downgrading to the industry standard of 44.1kHz, b). increasing sample width from 16 to 19. Since our code has very good use of macro-parameters thanks to Jolin’s integration efforts, these steps were done without too much difficulty. Right now, we are meeting our frequency requirements for all the notes below C6. This is not ideal, but within expectation, because the nature of using a division lookup table suffers the loss of accuracy in higher octaves.
  3. I went to the capstone lab to gather testing metrics on latency and frequency distortion using the oscilloscope and organized them into data that we will present in the final presentation. I also took lots of screenshots and some videos on some of our features, e.g. ADSR, PWM, and polyphony. These can be used in our final videos.

I am currently on track and looking to finish my work on time.

Before the final presentation, I need to:

  1. Write a Python script to compare the shape of our three fundamental waveforms with the ideal shape in order to evaluate our waveform generation approach using a period table and a division table
  2. Help make the testing and verification part of the final presentation slides and do a mock session to help Jolin prepare for the real presentation

Lastly, after the final presentation but before the demo, I am planning to do one last adjustment to my part of the project by tweaking the ADSR module to prolong the maximum duration of each stage. I planned the stages to be 1 second, but with the unforeseen upgrade of frequency rate, this number dropped down to 1/8th of a second… I need to increase the bandwidth of my envelopes to counteract this side-effect.

Jolin’s status report for 5/1/2021

  • I integrated the unison detune feature and made sure the whole system works well. I am integrating ADSR and adapting the existing division table so that the oscillator and ADSR can share the same table.
  • As I was implementing the arpeggiator, I found out that the arpeggiator functionalities we originally planned to implement have already been implemented by the keyboard. With the MIDI message the keyboard sends, we don’t have enough information to recreate the same functionalities in FPGA. The keyboard only sends out MIDI note messages at the configured rate and pattern. It does not send control_change messages for the arpeggiator configuration buttons and it’s impossible to figure out which piano key on the keyboard is pressed based on the MIDI note message since the octave transpose makes 3 keys being able to produce the same MIDI note message.
  • After discussion with Hongrun and Michelle, we decided to implement a “record-and-cycle” function instead. This feature allows the user to have a custom “spacing” between the notes, not just 1/4 notes at some tempo like the arpeggiator. This feature is not so different from arpeggiator on the implementation level in the sense that both functionalities capture notes and then play the captured notes at some rate. We think it augments the arpeggiator feature and is a good proof-of-concept for what we originally would have implemented. Users still get the same functionality.
  • To compensate for the change to the arpeggiator, we decide to add pre-configured stored wavetables and add the functionality to modulate between two waveforms.

I think I will be able to finish everything by the video deadline.

I will work on the remainder of the record-and-cycle feature and the modulation feature next week.

Team status report for 5/1

This week, each of us worked on a special effect (ADSR, unison detune, and arpeggiator). We performed some verifications of our system, and we were able to resolve any issues we encountered after communicating online. In preparation for the presentation next week, we started working on a slide deck, and we will probably be helping our presenting team member practice prior to the actual presentation.

Currently on our Github repo, the system on our main branch is several commits behind, as our effects are all pushed onto separate branches. Next week, we will be focusing on integrating and producing a complete product on the main branch. The biggest issue we may encounter is that we have slightly different configurations across our branches, but this issue shouldn’t be too much of a hassle, since we tried to write robust code.

Michelle’s status report for 5/1

This week, I was able to successfully synthesize and hear notes being played through a speaker. So I was able to test out my unison detune design, and I made some changes on the parameters. I also did some preliminary verifications for frequency distortion, and worked on the final presentation slides with my teammates.

Next week, we will be focusing on integrating the effects we each have implemented (ADSR, arpeggiator, and unison detune) into a final complete product.

Michelle’s status report for 4/24

This week, I was able to connect the entire system. However, I am having some trouble with synthesis. I am receiving warnings about pin assignment and some entities within the design not being found, but I am using the same QSF files as my teammates. I wasn’t able to resolve these warnings.

Next week, I will be working closer with my teammates to try and solve these issues, so that I can actually test some of the design changes I have made previously.

Team Status Report for 4/24

This week our team is a little bit behind. According to the plan, we should be able to finish this week, but we are still working on the last two features, ADSR envelopes and the arpeggiator. We anticipate that we need to work on our project a lot more next week. Our to-dos include:

  • finish our final presentation slides and practice it
  • verification and testing
  • finish and integrate all features

The biggest risk factor to our project now is time. As finals and all the end-of-semester projects kick in, we are finding it harder and harder to consistently work on our project. What we will do is to check in with each other on a more frequent basis in the following week, perhaps by setting up an additional meeting time.