Reverb Implementation

I got my reverb algorithm working today. w00t. In the end, i opted for a reverberator based on Schroeders one outlined below. It incorporates 4 feedback comb filters in parallel with 2 allpass filters (in series). The filters were both based on the methods outlined here. After these were designed, it was simply a matter of throwing it all into a function with user defined parameters. the input gets chucked through the 4 feedback filters, the outputs of which are added together. This summed out is then put through the first allpass, and the result of that is used as an arguement for the second. The output of all this is then added to the original signal and then the whole signal is normalised to ensure the volume remains the same as the input signal. phew. Now i just have to test out sample inputs to see what we should restrict the parameters to be in the GUI.

Meeting with Alistair 21/02/08

We met with Alistair today to show him what we had so far and to discuss a few issues we were having. He seemed pretty happy with our project so far. The issues that we dicussed with him were the tuner and reverb.

My main concern with the reverb was the computational complexity of the techniques. Alistair suggested that since we werent adding the effects in real time, convolution reverb might be the way to go. Even still, I think Im leaning more towards my man Schroeder….

As mentioned above, we also discussed the issues we are having with the tuner. The problem here is that we need to read in a constant stream and analyse it on the fly. Alistair suggested just recording at itervals, preforming the fft and analysis on each recording and outputting the result back to java. This is probably what we are going to end up doing. The key here will be to get the balance right between the length of the calculation and the length of the recorded samples so as to minimise any delay in the output to the actual program. This is very important because of the nature of the tuner, as the user will be turning the marchine heads based on the needle displayed in our system. So if our needle isnt being updated as close to real time as possible, the user wont tune their guitar properly.

Distortion

We got distortion working today. Turns out its really easy to implement in Matlab. The function simply takes in a parameter from the user defining how much distortion should be added, multiply it by 2 and then mulitply the input signal by the result.  We then get the inverse tangent of this and boom, the signal is distorted. The signal needs to be normalised after this to ensure the volume remains the same as the original input signal. Distortion proved to be quite a simple effect to implement, but we think this sounds quite good. It does a nice overdrive to full on fuzz.

Delay

Reverb looks like its gonna be a little complicated to implement.

I had a brief look at delay today, and reasoned that its going to be a lot simpler. The basic idea is to copy the sample and keep layering it on top at intervals to create an echo. We both decided to have a crack at implementing this, to get us in the mindset of programming effects in Matlab. My implementation worked quite well for up to 3 repeats, but after that started spitting out intermittant matrix limit exceeded errors. Conors initally worked perfectly for any number of repeats, but expanded the sample exponentially to the number of repeats and so left a massive length of silence at the end. He quickly fixed this (cos hes good like that) and boom, suddenly we were having great fun with adding delay to our recorded samples. I added a simple few lines to make each repeat quiter than the last (to give a fade out effect) and we are now good to go to lob this into the GUI tomorrow. We plan to have parameters to control the volume of the echoes (with the fade out option), aswell as the length of the intervals and number of repeats. As far as we can see from online research, no one has implemented a delay where the user can specify the number of repeats in Matlab before. Chalk one up on the board!

This was great experience for us as regards writing matlab functions and looking at what is possible by messing with the waveform of a sample.

Reverb Research

I spent today researching various reverb techniques. The main methods i looked into were:

• Schroeders Reverberator
• Moorers extension of Schroeders Reverberator
• Feedback Delay Networks
• Convolusion Reverb

Schroeder proposed using parallel comb filters in series with all pass filters. This reverb apparently has a slightly metallic sound, but seems quite computationally efficient. One of his well known reverberator designs is shown below in fig 1.

Fig 1. Schroeder Reverberator with 4 comb comb filters in parallel with 2 allpass filters.

 

Moorer spent some time looking into Schroeders design and proposed using second order comb filters coupled with allpass filters. An implementation of this I came across used a low pass filter in the feeback loop of 6 parallel feedback comb filters. However, this doesnt seem to give much of an advantage tone wise over the computationally less expensive Schroeder reverberator outlined above.

Feedback delay reverbs are a lot more complicated that the algorithms described above, but also sound a lot more realistic. They were first described by Michael Gerzon in 1971 and 1972 (though Puckette/Stautner and Jot(whos reverberator simulates early reflections and late reverberation) tend to get the credit for the concept). The idea here is to split up the input signal into n delay lines of different lengths and the feedback gain g is replaced by a feedback matrix. An example of this is shown below.

Fig 2 – 3rd Order Feedback Delay Network (JOS)

 

This feedback delay network was designed by Julius Orion Smith III (JOS) of Stanford University.This guy really knows the score when it comes to this stuff. Check out some of his papers here. Anyway, Im not sure implementing a feedback delay network in matlab would be worth the hassle, as they are obviously very computationly expensive and, taking into consideration that we are aiming this system at beginners, i think a FDN might just be overkill.

Convolution reverb involes having an impulse response and just convoling an input signal with the impulse response. This, by all accounts, sounds awesome. The major drawback here is the lack of flexibility, as you are limited by the number of sampled impluse responses you have available to you. Also, this is again quite computationally expensive. This mad chap is doing good things with convolution reverb. His name is Fokke van Sanne, a dutch engineer who has spent what seems to be quite a lot of time firing starter guns in vaiorus settings and then using Altiverb software to remove the sound of the gunshot and create a sample of the sound of the space. This is your impulse reponse. Once you have this, you can convolve any input sample with it and it sounds like it was recorded in that space. Heres a picture of him firing a starter gun into his mouth -

Its pretty neat, but a little overboard for this project I feel.

Anyway, at the minute it looks like I will be implementing either a Moorer or Schroeder style reverb for this system. I found quite a good paper about implementing reverb algorithms in Matlab (check it here) , so im off to read that to see exactly how hard this is going to be…

Weapon of Choice

Today I read Alan Gostins research papers (available here) on the subject of note detection in pianos. This will be invaluable to us when we get to the key recognition stage of the project. Howeverone of the main faults identified with the note detection was the varying frequency spectra of different pianos. The algorithm Gostin came up with worked well for his piano, but not so well when he tested it on other pianos (cf Problems with Finding Frequencies). This will obviously be an issue we will have to take into consideration when designing the key recognition element of the system.

The guitar that we will be using for testing the key recognition functionality is a 2005 Fender American Deluxe Telecaster with Samarium Cobalt Noiseless pickups. Check it out:

Running a little behind schedule…

Progress on the project slowed a little bit last week in comparison to week 1. There were a number of reasons for this:

• Our decision to go back and recode the play/record functions in Matlab
• Getting our results for our Semester 1 exams
• Valentines Day (we are romantics at heart)
• Getting bogged down in complicated code

This last point is something we really need to look at. A major lesson learned this week was that its much better to keep things simple and get a functioning system first, and then go back and make it more complex if we have time at the end. It is very easy to get distracted and sped a lot of time trying to get something cool working(such as the graphical representation of the waveform), while an easier, albeit less cool, option is available.

I am fairly confident that we will be able to get back on track and knock out the effects processor module this week, provided we dont hit any more walls. This is the module we are both most excited about, so I reckon we’ll put in a good few hours on it this week. If i dont have it working by the end of tomorrow, I think I will leave the needle aspect of the tuner until later on in the project when i have become more proficient with Matlab.

and last week was a 6 day week

Due to the executive decision about redoing the record/playback functions in Matlab, we also had to rethink the graphical representation of the waveform. Conor solved this by again through Matlab by using the plot() function and exporting this as a jpeg. We can now just import that into our GUI. Sweet. The only thing about this is that it no longer has data such as the length of the recording and your current position.

I spent the day researching ways to read in and constantly analyse a continuous audio stream into Matlab for the second part of the tuner. This is proving to be a real pain. Hopefully i can schedule a meeting with Alistair next week to discuss it.

Write down 500 times – I love Matlab

So we spent Monday trying to incorporate the record/playback element that i coded last weekend into the overall system. This proved far more difficult than we anticipated. After a frustrating couple of hours we decided to have a quick look at whether or not this was feasible in Matlab. I discovered the audiorecorder script in Matlab and we had it recording WAV files within a few minutes. Thanks to the work Conor did making Java communicate with Matlab we can now just call these record and play functions in Matlab when the user clicks on the corresponding button in our GUI. This has saved us a lot of time messing around with Java classes which at the end of the day do the same thing.

The work i did last weekend wont all go to waste though, as we still plan to use the file chooser class for the save and load buttons. Lesson learned though – try things in Matlab first.

Happy Valentines day Matlab. <3

France 26- Ireland 21

I spent yesterday with one eye on the rugby and the other on java File Choosers. Using the JavaSoundDemo (available here) as a base, I coded our Record in/Play back module. This will occupy the top pane in our GUI, which the boy Mullen is all over (see his blog for a sneakpeak screenshot). I learned a lot about java files and audio input streams yesterday. The JFileChooser class is really useful and contains quite a few neat little methods that made the Save and Load functions a joy to code. This module also includes an image of the waveform, which for the minute I’ve lifted straight from the Java sound demo, because that one looks real pro. Depending on how well it fits in with the overall look and feel of our GUI, I might recode this at a later date.

We plan to integrate this modeul into the GUI on Monday. Today, Im going to have a wee look at the other aspect of the tuner – reading in a constant stream from the mic port and displaying a needle to inform the user whether they are sharp or flat of the nearest note. As Conor has sorted the ear training part of the tuner, once the needle is completed we will have the first major element of our system complete.