We got some good work done on the tuner today. I got to grips with Adobe Fireworks to produce the images for the graphical representation. Fireworks is an awesome piece of kit, with buckets of features and options, and so it took me a little while to get to grips with it. We reasoned this time was well spent though, as we now have unique images for our system, rather than ones lifted off the net, which is what we were originally going to do. Hopefully we’ll get to do a bit more in Fireworks (the music theory tutor and some more logos spring to mind) if time permits.

Conor started integrating the tuner into the GUI. He is using a nice class called RotatePanel (described here), which ensures a smooth transition between the needle states.

Anyway, heres a screen shot of how it looks so far:

We started seriously looking at the tuner again today. We want to have a moving needle that moves in as close to real time as possible. The hard part here is that Matlab needs a longish (when we are talking in real time) sample to analyse. We need to find a balance between the length of the sample Matlab needs and what is an acceptable time delay for th euser to experience. For the minute, we’ve settled on a 2 second sample, but it may prove that this is too long.

We read this into Matlab using audiorecorder, pausing every 2 seconds.

The method we wrote in Matlab finds the fundemental frequency (which, for the tuner, will usually be the first note encountered in the sample, or else the highest peak) of the note and outputs it back to Java. This is quite easy to accomplish as all that is needed is to FFT the sample, find the highest peak, divide this by the length of the sample and multiply it byt the sample rate (divide by 2, mulitply by 1 in our case as the sample is 2 seconds long). This method works, in that it returned the correct note to us during testing. It remains to be seen if the 2 second sample is too long once we get a graphical representation of the tuner into the GUI. ..

Ive added the clear all button and a 3/4 time option to the Groovebox. 3/4 time proved to be a lot more difficult than I anticipated to implement. Jtable can be quite annoying when it wants to be. My perseverance paid off though, and the way it stands now you can easily which between 3/4 time and 4/4 time without reseting either beat – which is nice.

I also added a slider for changing the BPM that allows you to change the tempo in real time. The current BPM is displayed in a text box beside the slider for fine tuning.

Here are the promised screenshots of the finished module:

Fig 1 – GrooveBox, 3/4 Time

Fig 2 – GrooveBox, 4/4 Time

I rethought the technicalities of the Groovebox and decided it wasnt feasible to create it in Matlab. So I did some more research before arriving at the solution i had been looking for:

Midi.

Midi stands for Musical Instrument Digital Interface. Midi doesnt transmit an audio signal. Rather, it simply transmits digital data “event messages”. This solved my problem with the pitch issues when changes the tempo of the drum loops. It also solved my sample decay length problem as it just so happens that there is a midi class in java sound. This has solved all my problems quite nicely.

Since settling on midi drums, I have been working on putting the whole thing together. I now have a fully functioning Groovebox that Im quite proud of and that works well. There are a few things Im hoping to add to it, such as a clear all button to reset the table, but as it stands Im happy out with it. Ill post a screen shot of it soon.

I decided to go with the Jtable option for the groovebox because it will cut down on the lines of code involved, and also because i think it looks better (this is probably due to years of messing around Fruity Loops). With that decision made I began to look at how a loop would actually be created in our system. I dug up some old drum samples i had sliced up a while ago and began trying to put them together in Matlab, using the function I described in a previous post. This worked to a certain extent, but i began to run into problem when it came to instruments such as crash cymbals that have a longer decay time than say a snare drum. The problem here is that the crash decay needs to extend out over the other instruments. As it stands, my function waits for the crash sample to finsh before concatenating another sample onto the end of it, which puts the whole loop out of time.

Also, more worryingly, increasing or decreasing the tempo squashes or stretches the loop, resulting in undesirable effects. Time for a rethink…

We had a meeting today to keep Alistair updated with what we have working so far. He seemed fairly impressed by all the effects. He did suggest that we look a pitch shifting effect, which we might go back to at the end of development if we have time. At the moment we have 7 working effects, which we think is enough for now.

Other than that, we just discussed our plans for the week, namely me continuing work on the groovebox and Conor doing some redesign work on the GUI to make it more object orientated.

We finalised our TEF effect today. We decided on 3 different parameters, which we called repeater, synth and convolution delay.

Repeater basically takes your input signal and replicates it. This is then fourier transformed and values at a user defined interval are set to zero. This creates a loop of a part of the sample. The length of the loop is inversely proportional to the interval defined by the user. The original signal is then added over the loop. This adds an interesting depth to the sample.

The synth effect is basically a low pass filter where the sample is fourier transformed and every value underneath a user defined value is set to zero. The greater this value, the more ethereal the sample becomes. Very cool.

The convolution delay is a random effect. it allows the user to set up their own impulse response by allowing the number of teeth of a comb to be selected. The neat thing here is that it then places these spikes randomly on the comb. This comb is then fourier transformed and multiplied by the fft of the orginal sample (convolution). This leads to some really cool random effects. The greater the number of teeth, the more complicated the effected sample becomes.

This effects are pretty unique, and you wont find these combined into a stomp box anywhere. We feel that these effects will help to add originality to our system.

I spent the weekend thinking about the groovebox. I threw together some sample designs for it – one using a Jtable and another using checkboxes. The checkboxes would work well, but it would involve creating 64 checkboxes (16 instruments x 4 bars (with 4 beats per bar)), which gave me 1500 lines of code before I even began to code any of the complicated stuff. So I dont think Ill end up using checkboxes. The Jtable works a lot better lines of code wise, but is quite tricky to use. I spent half of today trying to get a cell to change colour on a mouse click, and in the end I just gave up. The problem is that the cellRenderer() method is part of the column class, so Jtable is more geared towards editing entire coolumns at once, rather than individual cells. I did manage to change the colour while it was selected, but the colour changed back to white once a different cell was selected. Ill have a look at this again later in the week.

On the Matlab side of things I wrote a nice method that will take 2 samples as parameters and add the smaller of the samples on top of the lafrger one. This will be useful for when more than one instrument is to be played at once – ie, when more than one cell in a column is selected.

Im going to find some decent samples for the instruments soon and try and normalise their lengths as much as possible to ensure that they keep in time with eachother.

I spent today working on an Analog delay simulator based on our current digital delay. Analog delay differs from digital delay in that the echoes  arent exact replicas of the orignial signal and they deteriorate over time. Many prefer analog delays to digital because they are seen as “warmer” to the more sterile digital delay. I myself like both, feeling that both have a place, and both serve different purposes. That is why i decided to integrate a simulated analog delay into our system.

I achieved this by fourier transforming the original signal and setting all values under a certain value to zero, then inverse fourier transforming the signal and using this inverse transform as the echo. This is repeated for each echo, so that each one degrades a little bit more than the last one. This creates a much lusher sound than the digital delay. The nice thing about this is it is based around the digital delay Conor developed and so takes the same parameters. Because of this, when integrating this into the GUI, we just added a checkbox labeled “use analog sim”. This cuts down on cluttering up the GUI with extra sliders that would just do the same thing anyway. It also allows you to easily hear the difference between the analog sim and the digital delay.

After a day spent messing around in the frequency domain, we have decided to add a unique effect to our system – the TEF Effect. This will consist of a number of user definable parameters that will edit the fourier transform of the input sample. These will do things like set some values to zero and set every value below a certain number to zero. Doing things like this do crazy things to the sample once it is inverse fourier transformed.

More on this soon…