An Arduino Nano? What a waste... Just use a PIC or an ATTiny. Spending even $1 for something so simple is unnecessary.
For personal projects, it's not often the case that you need to get BOM cost as low as possible and disregard other factors (like debuggability, or having enough DSP available to run the FFT for tuning calibration (though I suspect they'd be better off with autocorrelation...), or room for future expansion (adding multiple channels, adding a sequencer, adding control over the filter, implementing envelopes, running the Pi's audio output through the filter too...)
Plus, they might have had the Pi before, and still have it afterwards. That's the nice thing about general-purpose computers- you can put a whole bunch of different software on them, and then switching between uses just involves moving the board itself and plugging cables in.
One functional advantage of a microcontroller over a single-board computer is lower latency due to not having the overhead of an operating system.
Also, the Pi's built-in audio output is basically unusable, but easily replaced.
However if you dont have floating point arithmetic like many microcontrollers, fixed-point DSP for FFT or autocorrelation presents its own set of challenges, which can be either a good thing or a bad thing.
I remember when I built my Minimoog clone in highschool I had to not only etch and drill a board for the midi2cv convertor, but also one for a parallel port PIC programmer to program the PIC it required. I think the parts for the two together would be around $100 adjusting for 15 years of inflation (of course, that was dwarfed by the parts cost for the synth).
I get that my solution is a little more expensive. But, actually the whole thing costs ~$25, not $40, if you buy the three components thriftly (used Pi ~$15, usb audio adapter $5, mcp4725 $5).
In contrast, that link you mentioned has over 15 parts instead of 3 parts, and it needs to be on a PCB/breadboard. The total cost is cheaper (probably $10 if your thrifty) but requires way more effort IMO than using a Pi.
Crucially, I've never seen any MIDI to CV that provides a method for automatic tuning which is very time consuming. Using a Pi provides that easily and automatically with sox.
I'm not sure that has the automatic feedback system to calibrate voltage to note on arbitrary synths like is the bulk of the work listed in the article.
this is the real win they got from using a raspberry pi - they could throw a cheap usb audio interface on it and get a feedback system. They could, of course, have done this using an ADC on a cheaper microcontroller - but it would have been a lot more coding to write the audio input and calibration from scratch.
That's actually not an equivalent. If you're going to bitch and try to diminish someone's achievement then at least do them the favor of reading the article and understanding what makes it unique.
My suspicion is you didn't read the article, because the README for this otherwise quite awesome-looking project doesn't mention anything about doing FFTs on a $3 microcontroller, like the article author did on their Pi.
Then again, if I missed it and you can do those FFTs with this project, that's pretty cool.
This is super cool! Using an FFT to detect pitch is a natural approach, but my understanding is that most pitch detectors work in the time domain using some form of auto-correlation. See:
For this I used the simplest approach I could think of - using sox [1] with its builtin power spectrum analyzer. It works pretty well as the resulting tuning is fantastic. It would be nice to a faster pitch detector - could speed up tuning from ~15 seconds to maybe just a few seconds.
I used this to detect the switching frequency in DC-DC converters at my first job after a colleague gave up with trying to use FFT (way too noisy). The signal was barely visible with the oscilloscope I was using, but it worked great and caught many problems! I thought up the solution myself, but didn't realize it was widely used.
Auto correlation is best used for those frequencies where the FFT does not work (for instance, due to a too low number of FFT buckets to reliably detect which frequency you are talking about because multiple notes map onto a single bucket).
Nice. :-) Having done somewhat similar stuff before, I'm curious if you were able to measure what the latency result of using linux and python was vs doing it with an MCU like a teensy or arduino and using C? I can see advantages to both approaches, and am genuinely curious. There must be some latency and unpredictability added, but maybe it's small enough to totally not matter. Off course whether this matters depends too on the controller keyboard and your playing level, I know what is ok to me differs from what what my Real Pianist friends tolerate!
When I measured jitter I found that it was higher in cheaper instruments [1], so I think it might be dependent on the hardware that is listening to the MIDI output.
They are (besides the Monotron Duo, which has a second oscillator (but no way to play it paraphonically without hardware hacking, you can just tune it differently)), but this is the Monotron Delay, which has, well, you can probably figure that out.
What I'd love to see is if they could use the same tuning system they used here to tune the delay time and make the monotron delay do some kind of karplus strong synthesis! That's assuming there are patch points for the delay time, I guess...
you can accomplish this by automating VR6A on pin 6 of the pt2399. one oldschool method to add CV control of a potentiometer is to control the resistance with a vactrol.
Yeah, the monotron is monophonic. But you're ear is right on because it does sound like multiple synths - I'm actually augmenting the monotron a bit here using another device called the norns [1] with a script I wrote [2] which converts the initial drone note into a drone covering six different pitches at various volumes (sort of a super saw). After that augmented drone you'll hear an arpeggio which is pure monotron (plus its delay which adds a little polyphony as mentioned).
I created a midi piano in the browser for a Roland EP7 IIe that sent midi note off in a weird way - causing double notes , it would send the same note but with just the velocity information changed to 0, which most midi software didn't like.
Sending a noteOn with 0 velocity instead of noteOff is surprisingly common among MIDI keyboard implementations, so Im surprised that a lot of software wasn't handling it well.
It's not just common, it is part of the MIDI specification and deliberately done that way to allow running status, an optimization that was important in the days of (true) serial MIDI.
Which midi software did not like that? It is so common I build support for that into all my midi projects, so I'm kind of curious who would not support it and why.
This is great. And miti is exactly what I was looking for. Started working on something similar in bash and perl on top of gbevin's sendmidi [1] a while ago, but this looks like it'll save me much effort. Thanks!
Thanks! That's a neat solution! If I had seen that before, I may not have made miti :)
I found there's other few programming-friendly simple MIDI sequencers [1] but generally none of them were simple enough for me. I'm pretty happy with the simplicity and power behind miti and use it quite a bit for my own purposes. Feel free to ping me if you have issues with it or ideas to improve it!
Brilliant trick to self calibrate, these are probably each different enough that if you hooked up another one to the same PI it would come out all out of tune.
