NanoEgg Music Synthesizer

So, in anticipation of needing all of the pins and pads on the Teensy to accomplish my dark work, I have revisited my Teensy pin expander project "Megsy", adding support for an external USB socket, and better placement for the bottom pads, and better routing so that it might be made on an OtherMill PCB router.

Full project log is in the Megsy project here.

As I'm anticipating having access to a PCB milling machine in the near future, I've started work on preparing PCB files. I have learned a few lessons from the first PCB I had made for the Twister project and so I'm applying them here.

First: I realized that placing all of the connectors in random orientations in odd places around the board was a bad idea when it came time to wire it all up, and so I should endeavor to keep all the I/O in standard places.

Second: It is also a good idea to keep all of the chips pointed the same direction wherever possible, so that one doesn't get confused and install them backwards!

Third: The default footprint for the component might not be the most economical use of board space. Believe it or not, I didn't realize that you could select different package shapes. I've done that now.

Fourth: When using a router to make a board, having a ground plane will greatly reduce the area that needs to be routed out. Good PCB CAD programs can do this easily, and so can Eagle!

Fifth: Since this is a prototype, it is probably handy to make each system as a separate board, or at least keep all of the components localized to one section of the PCB. This makes it easier to find and debug different parts of the system, and if the separate board route is taken, one can reconfigure the features and pins used as necessary. This is especially important when using microcontrollers, as you may have very limited I/O resources, and thus need to shuffle around which pins are used for what when you add functionality.

Sixth: The Arduino form factor is really kinda terrible because you can't put a shield into a breadboard for testing, and it kinda precludes using that hardware with any other type of microcontroller. I'm going to make things as separate modules and only make a "shield" when I'm ready to set in stone.

Seventh: It's really good to mark the orientation and pin numbers of connectors on the board in some way, so that you don't have to load up the schematic every time you need to unplug or replug the board.

Eighth: Pin headers are really not fun to crimp. Try to design using something different.

Ninth: Pin headers come off randomly unless you are using the locking kind.

Tenth: If making stacking boards like Arduino shields, be sure to keep track of the height of elements on the board. I found my board resting on top of the USB connector, which meant the board didn't seat completely on the headers, and with all of the cables plugged into it, the Arduino didn't fit in the slot I had left specifically for it in the case.

Eleventh: Some stuff uses 3.3 volts instead of 5 volts. Often you can switch your circuit to work with one or the other by simply changing the values of some resistors.

My education continues!

So, I've written a fairly long-winded war log of debugging a stuck notes error that occurred when playing the NanoEgg prototype through my Twister controller box. It lives at: https://hackaday.io/project/8027-twister-a-play-on-midi-controllers/log/39746-debugging-stuck-notes

As it turns out, the problem wasn't in Twister at all, nor in the hardware as I suspected. It turned out that there was a bug in the MIDI libraries on the Teensy that had never been updated since version 3.2 (latest is 4.2).

But I got to spend some quality time with an oscilloscope I borrowed from 23b Shop, so it's all good!

I'm just happy that it's all been fixed now!

Having generated the waveform data and tested it in Shadertoy, the next step was to convert it to C++ code and write out to datatables to include in the synth code. This was a little trickier than expected for some reason... you'd think the math would all work the same, but it actually required a bit of rework to get the same results. I ended up making the code more explicit about samples, transition steps, and segments of the continuous waveform, and I rewrote all of the transitions to use a smooth-in/smooth-out transition (basically cosine from PI to 2*PI).

In order to check to make sure my results were correct, I decided to graph the text output datatables. That was a good thing, because there were a lot of problems!

First, I tried LibreOffice, but it kept choking on my dataset and would just hang forever. I have to keep reminding myself that LibreOffice is a really terrible program that will always let me down.

Next I tried an online program called Plot.ly. At first, I couldn't get it to do a height map with my data, but it turns out that was just a problem with the version 2 beta they tried to force me into. It works fine in the original version.

One of the great things about doing this in Plot.ly is that it lets you spin the graph around, which was really handy with a 3d graph like this when I wanted to understand exactly what was going on with the data.

I probably repaired and re-uploaded the data about ten times before I finally got the proper data that you see here.

The next thing was to actually put the data in the program. Surprisingly, I had actually written the code correctly, and even though there were an order of magnitude more waveforms, it actually went in quite smoothly, with minimal changes to the code or the configuration data.

Everything sounded good, but I wanted to give one more test to make sure everything was working as implemented, so I found a PC oscilloscope program called Visual Analyzer (which is very nice and I highly recommend it) and used it to generate this video, which includes not only the time-domain output waveform, but also the unknown pleasures of the frequency domain spectrograph of the sound.

One of these days I'll be able to generate a screen video with a good framerate that isn't compressed to the point of blurriness... the struggle is real!

I initially had some trouble getting the waveform to not jitter and stay on the screen. The "trigger" works pretty well, but not perfectly, especially when I am changing the waveform with the knob. I could turn triggering off, but there was no way I could find to dial in the refresh rate of the scope. Eventually, I just adjusted the pitch of the synthesizer until the waveform stayed on the screen.

At the end of the video, I messed around with multiple oscillators, waveform sync, and filters a little bit. It looks prettier than it sounds...

So, I added some features to my waveform calculation equations at Desmos.com, namely a smooth transition between sinewave and triangle wave, and pulse width modulation on squarewaves.

(This was supposed to be an awesome embed from ShaderToy, but the site ate it so you just get a poorly captured Youtube video.)

Ultimately, the goal is that you will be able to turn the knob and smoothly select between all possible waveforms. You might even be able to attach it to an LFO. It would be nice if you could adjust the sine-y ness, square-y ness, and duty-cycle independently, but there are already so very many knobs on this box, I think that will be too much...

The great thing is, now I have a block of (rather messy and bad) code that can be used to generate all the waveform tables I need for a nice continuous knob transition of waveforms. If I have 127 waveforms of 256 samples each in 16 bit quality, it should come out as a bit less than 64k, which should be fine given the 256k of Flash in my target platform.

The next step is to generate those tables and include them in the software!

Since this project is to have at least 42 knobs and a keyboard, I need to find a way to multiplex those inputs for use with the Teensy, which simply does not have enough analog pins for all that. I'm strongly considering the 74HC4067 analog multiplexer, but it is really hard to find a DIP socket version of it to breadboard, especially for any sort of reasonable price.

I'm also wondering if I might need to use a completely separate processor to handle the input stuff decently. My other project "Twister" might end up being a part of the NanoEgg after all...

I've been thinking for awhile now about a better way to handle the waveform select knob. I'd like to have one knob smoothly transition between all of the standard waveforms, with the option of selecting something in between. It would be easy to have several knobs that control the mix of all of the waves, but that is a lot of knobs, input lines, and panel space.
Let's see if we can do it in one!

In order to generate these smooth transitions between waveforms, I need to actually have equations for them. Making equations for sawtooth waves that turn into triangle waves is pretty easy, just line slope calculations after all. But making a sine wave that can skew was a little trickier..

So I currently only have a moving saw - triangle wave, and a deforming sine wave. Fortunately, the other inbetweens for the other waveforms can easily be generated by using LERP interpolation between the points. I'll store waveforms for Saw to Triangle, then LERP from triangle to sine, and then again to square.

From there I might start decreasing the pulse width, then transition to an exponential saw and back to the regular saw for full circle.

I'm worried about how much RAM I am going to take up with waveforms. It would be nice to calculate them on the fly, but I think it would be too slow...

So, the reason I haven't been posting a ton of updates here is because I've been working hard on my "Twister" MIDI controller (knob box) project.

https://hackaday.io/project/8027-twister-a-play-on-midi-controllers

Twister was originally conceived as the programmer / controller for the earlier version of the NanoEgg (before it had it's own knobs). I'm using my work on Twister to learn the ins and outs of dealing with analog control knobs on a digital device. The Twister boards and case were done, so I determined that I might as well complete it.

Twister is based on the Arduino Mega 2560, and there is a temptation to use that as a controller for the knobs in NanoEgg too. But I am learning that the resolution on the A/D is not so great, and it seems a lot slower than I thought it would be, so maybe that isn't a good choice after all.

Found myself at Fry's Electronics and was delighted to see they had a selection of the appropriate knobs too. Prices still terrible, but I got a look at what 3/4" and 1" diameter knobs and have a better feel for the scale now.

They are too damned big.

I guess I'll have to 3d print my own if I want micro 1/2" diameter knobs.

I found myself in the local big box hardware store, and so decided to price out various physical components for the box.

Hinges

Wood

Yes, they want $13 for a thin bit of wood. Perhaps other sources need to be found.