Clock/Sequencer
My housemate works with modular synthesizers and is eager to start building her own devices. As an introduction to working with microcontrollers, soldering, and building solid state systems, I made her a deal: if she finds what to build, I’ll help her build it and teach her whatever she needs on the way. Win-win for me, I love teaching and building but I’ve always had a hard time coming up with what to build.
Well, pretty quickly she came back with this clock device she found a guy make on Youtube. It’s designed for modular synthesizers, uses simple parts, an Arduino Uno as the controller, has some nice LEDs as visuals and, most importantly, he had the code and schematics up on GitHub. So with plans in hand we set out to start building it!
It was definitely a bit of a learning experience. I’d not worked enough with schematics to recognize that the provided were specifically for a PCB, utilizing a ground plane, so it took us a good while to figure out exactly how it all fit together. Not to mention he has a ‘VGRND’ looking RC circuit that links up to the negative input on each of the OpAmps, however that is not clearly communicated on the circuit diagram so it took a little time tracing some pictures of his PCB we were able to snag off his old Etsy sale page for them.
Here is a video of some early screen functionality (you can see the LED in the background blinking).
https://photos.app.goo.gl/ADSHBUG2YMjsRzBE9
This circuit has only one of the OpAmps, but shows the LED screen we’re using to visualize BPM, run the sequencer, and allows us to select from pre-programmed sequences. It also shows some mechanical keyboard switches we turned into push buttons.
We had a couple early bugs that took some ironing out. We didn’t copy his code wholesale, rather used it as a scaffold for building ours on top so it was expected to a certain extent. As you can see in the video above the LED had some blinking problems. What you can’t see is that it was VERY quickly falling out of sync with a metronome. A little code hunting and I found two and a half main issues.
The first main issue was with how his code tracked when it needed to pulse a beat.
If it doesn’t pop out to you that’s fine, it didn’t to me either and I’m both a music person and and programmer. The issue is with how he tracks when he next needs a beat.
Get Mhalleck’s stories in your inbox
Join Medium for free to get updates from this writer.
At the beginning he calculates bpmDelay, which tracks how long between each beat. If the current time minus the time he last did a beat is greater than that value he knows his code needs to do another beat. And this is where the problem lies. The arduino nano doesn’t have a very fast clock at only 16 MHz, so oftentimes by the time it gets around to checking whether it needs to do another beat it’s usually late by some fraction of a second. Usually between 5 and 50 microseconds, but this can get as high as 50000 microseconds or 50 milliseconds. For reference if you are beating at 120BPM that is once every 500 milliseconds. But we aren’t, our resolution is actually higher to allow for subdivisions like quarter, eighth, and 16th notes, so we are actually tracking a beat once every 62.5 milliseconds. Suddenly a 50 millisecond offset sounds real bad.
Now, every now and then hitting a beat late isn’t so bad, in fact that can often be desirable for chorus effects. But instead of just beating late his code compounds the error by recording what time he has just beat. In an ideal world if you’re beating every 62.5 milliseconds your next beat should be the last beat + 62.5 milliseconds. But because the arduino lags behind sometimes if we decide to do the next beat 62.5 milliseconds after the current time we’re going to incorporate any delay.
The fix, once we identified the problem, was thankfully easy. All we had to do was change how it tracked when it needed to do the next beat.
This is also where the half problem comes in. See, his code used milliseconds to track time as opposed to microseconds, losing a decent amount of precision.
After fixing those the problem was still pretty bad — it seemed somewhere in our program there was some code that was really slowing us down. A bit of process of elimination showed it to be the library/routines that updated the LCD screen. Compounding this was the fact that instead of only refreshing the screen when things changed my code had it refreshing every 50 milliseconds.
Those two things improved things immensely. I also had the thought that, if it is the code that updates the screen that takes so long then we should only do that immediately after pulsing a beat so as to give the arduino the most possible time between the LCD routine and when it next needs to beat.
All of these improvements has led to a program that, even when constantly cycling between screens, does not fall out of sync and beats, at most, 20 milliseconds late, and more regularly the normal, 0–50 microseconds late.
https://photos.app.goo.gl/SuvJ9ojVyR2ADF3U8
The next step is hooking it up to the rest of the 3.5mm jacks and adding the sequence selector. We’re also going to be adding the ability to modify the selected sequence values.
