I’ve spent a lot of time in the development of the Rockit 8 Bit Synth dealing with aliasing. I made a MATLAB simulation to get to the heart of the issue visually. The script simulates the wavetable synthesis process by generating a sawtooth wavetable and playing back that wavetable to generate a 50% duty cycle square wave output. This output is plotted along with the Fast Fourier Transform (the frequency) of the signal By adjusting some parameters, the amount of aliasing in the signal can be increased or decreased, providing a visual tool for understanding the factors that contribute to aliasing in wavetable synthesis. Click through for a thorough explanation.
I’m making progress on testing the latest board and I got it making some noise. But, it’s not all the noise that I was looking for. It’s more! Specifically, I made some layout choices that turn out to be quite poor. Let me save you from making the same mistake. Click through for the details.
Take a guess and click through to see if you’re right!
In a previous post, I discussed how in setting up my oscillators, how I made a proper demonstration of aliasing. I have yet to find a clear description of the problem as it relates to digital synthesis. There are many sites which define aliasing in engineering terms but don’t make it as easy a thing to understand as it can be. Follow along as I give it a shot.
So, I’m deep in embedded software, or as people in the know call it, firmware. A lot of what I’m dealing with is rookie nonsense. Now, I’m probably more of a journeyman coder at this point, but good high quality code doesn’t just spring from good intention and effort. There are a great many rules and tricks of the trade that can only really be learned from someone else. I, being self-taught, have learned much of what I now know by blindly stumbling through the wilderness until through sheer effort, I find the way out of the woods of impenetrable error messages. I’m going to be sharing over the course of many posts, some of the rules and best practices that I discover along my journey. Hopefully, they’ll shorten the duration of your meanderings. Follow the jump for a discussion of the use of the preprocessor directive, #ifndef.
In Part One about the MCP23S08, I discussed how to set up one of these i/o expanders as a bank of outputs to drive LEDs. They can also be used as digital inputs. They don’t do any good as analog inputs for things like pots. You can use analog multiplexers for that. As digital input expanders though, they make an excellent way to expand your systems switch capabilities. I am using them for banks of tactile switches to step through options to control my synthesizer. Follow the jump to see how I configure them…
Twice now, I’ve been burned. I’m using the GNU C Compiler with the AVR ATMEGA164PA for my current project, the 8 Bit Synth. I need to use external interrupts to determine when a switch has been pressed. When it has, the i/o expander drops its interrupt pin from high to low. So, I set up the external interrupt routine to be falling edge-triggered. I had to figure out how to get the i/o expander to trigger its pin when a button was pressed. I knew that the i/o expander’s output interrupt pin was changing when I pressed a button. I also knew that the microcontroller’s interrupt service routine was being triggered because I made a pin toggle when the routine ran. I set a flag high in the service routine. I configured an if statement in the main routine checking for the flag. If the flag is set, I need to read the i/o expander’s interrupt latch register to determine which switch was pressed. The microcontroller never sends the read command. Not ever, ever. I couldn’t figure out why. Do you know? Follow the jump for the answer to this riddle…