Something Unreal

Up to 15 notes at once on an Arduino using no timers! Well, the quality drops a lot as the number of playing notes increases, but still!

[Watch in HD]

This is a demo of a MIDI synth I’m developing for the Arduino. Its sound is currently very basic – it has no concept of different instruments, can only produce square waves and noise, and each MIDI channel can only be at one of 3 different volume levels. It has no fixed sample rate, and is always producing a new sample as quickly as possible, which is slower when more notes play at once (in practise, the sample rate ranges from about 20 KHz down to about 6 KHz).

It supports pitch-bends, modulation, monophonic/polyphonic MIDI channel mode, and some percussive notes. It also recognises some sysex messages, including GM/GS/XG “reset” messages and GS/XG messages to set a MIDI channel’s percussion mode.

To use the code yourself (hardware info):

If you want the Arduino to accept MIDI data from “real” MIDI hardware (through a MIDI socket), you’ll need to build a circuit with an optocoupler and connect that to the Arduino’s serial RX port, and change #define UseRealMIDIPort False to #define UseRealMIDIPort True (this affects the baud rate used). Due to laziness, while testing, I used a program called “Hairless MIDI<->Serial Bridge” and the virtual MIDI cable driver “MIDI Yoke” to send MIDI data straight over the Arduino’s USB serial connection, instead of building the proper circuit.
The code controls one “port” on the Arduino (a group of 8 pins determined by the specific Arduino board model), which connects to an 8-bit DAC (a simple R2R resistor ladder) to give an 8-bit audio output. I’m using port C on the Arduino Mega, because that neatly corresponds to digital pins 37 (LSB) to 30 (MSB), but it may work on other Arduino boards as long as there is a port where all 8 bits are mapped to digital pins, with minimal changes to the code. The output port (PORTAudio and DDRAudio) would need changing to one consisting of 8 usable pins, and the maximum number of playing notes at once (NumSoundChans) could either be reduced (will save CPU time and memory) or, in the case of the Arduino Due, increased.

You can download the code for the current version here (13.2 KB). You will also need the Fast Division library (info). Note that the code includes most of the above hardware info in the form of comments. =)

P.S. The MIDI in the video is being played on MIDITester. I did not make the MIDI, and I don’t know who did. Please, people, at least credit yourself in the metadata ;_;

I’m working on an Arduino MIDI synth, and just tonight, I tried to add support for complex wave shapes (previously, it was only square waves and noise). Since I’ve now got enough working to be able to listen to these tiny (8-sample) lookup tables for different waveforms, I thought I’d make this video to show what they sound like. =)

(Also, I finally found a good use for block Unicode characters!)

[Watch in HD]

I made a program to send pitch-bend messages to Bawami (my MIDI synth) based on the strongest reading out of the X/Y/Z axes of the gyroscope on the GY-87 sensor board, via an Arduino. Gently moving the sensor makes for a really natural-feeling control for vibrato, allowing really subtle (or not-so-subtle) pitch changes.

[Watch in HD]

I was able to get readings from the board to Windows at a stable speed of 400 Hz, but to avoid spamming too many MIDI messages (a problem if sending them outside the computer to some hardware synth), the pitch-bends are “only” being sent at 100 Hz. =P

The GY-87 also has X/Y/Z accelerometers, but these were way too sensitive to orientation to be convenient to use as a controller. Gravity is always pulling down on one axis, so if you tilt the sensor then it massively overwhelms the readings that you actually want (the ones caused by moving the sensor around). The best use I could get from them was tracking the maximum difference between 2 points in time and sending that as a MIDI message, which basically just made it respond to vibrations (and only made positive numbers). The gyros naturally only detect changes, so the readings centre around 0 and go negative when turning in one direction and positive in the other, ideal for vibrato.

These are a few of the bits that I cut from the main video because it was too long, including running it at full speed and a comparison with a super-simple system! There’s a strobe light in this video, too.

You might want to watch part 1 if you haven’t already, so that this makes more sense.

[Watch in HD]

I threw this together from an old toy’s motor, old printer’s iR sensor, pizza box and some other things, to try out the PID controller algorithm after discovering it on Wikipedia and seeing that there was pseudocode, meaning that I didn’t have to get a PhD in mathematics to be able to read the crazy-looking formulas that Wikipedia seems to be so fond of. There’s a strobe light in this video.

I had planned to screen-capture my program while recording but completely forgot to at the time, so please try to survive my camcorder pointing at my laptop screen…

[Watch in HD]

Here, the PID controller is trying to keep the motor at a precise speed (and get it there as quickly as possible). It doesn’t work well half the time because the L298 (H-bridge), responsible for switching power to the motor, doesn’t seem to like making the motor brake. That means it speeds up much more quickly than it slows down, which the algorithm doesn’t like (it’s designed for linear systems) – it basically ends up trying too hard to slow down, resulting in a big undershoot. I might be able to somewhat compensate for that in code.

I might try this with a Sabertooth motor speed controller (as used in my old singing motors project) in place of the L298, which can certainly force a motor to stop spinning, but the Sabertooth gives such a boost to the motor to get it up to speed that 90% of the PID’s job becomes redundant… Oh well, at least it’d be able to hit any given note without me having to calibrate it first like I did with the singing motors. By the way, that’s why this system measures speed in Hz – I originally intended for it to play music like a new kind of “singing motor”.

Originally, I planned to use a 3-pin computer fan instead of this motor, using the tachometer pin to measure the speed, but that required me to have a common ground for the motor and the tachometer, and I didn’t have the right components available (I only had N-channel MOSFETs, but I needed a P-channel MOSFET). So I ended up throwing my own motor assembly together and using an N-channel MOSFET only (could only turn power on/off, not brake), which the PID system didn’t like. I thought the L298 would fix that problem, since it’d allow the PID system to reverse power to the motor and brake it, but it turns out it’s too weak to have much of an effect after all… =/

Part 2/2 will show it running at full speed (with a more powerful PSU), show a much more naïve speed controller algorithm for the lulz, and just clear up a couple of details.

I’ve given her another 2 ultraound sensors on either side, so that she can see how well lined-up she is to walls on either side of her. This is to try to keep her heading directly towards a wall, so that the head ultrasound sensor will get the best reflections possible (assuming that her environment uses lots of right-angles).

[Watch in HD]

The Arduino fires all 3 ultrasound sensors and listens for their echoes at the same time in order to “see” at the highest frame rate possible (typically 20-50 FPS), but this causes issues with echoes from one sensor bouncing around and returning to a different sensor. Although the code avoids any clearly-bad echoes like this (e.g. 2 echoes on the same sensor), it’s far from perfect, and she often thinks that she’s crashed into something (an object is very close to the head) when she hasn’t. I think there’s also a strange bug in the function that times the echo delays, or something strange is going on with hardware interrupts, because the function sometimes returns 0 for a sensor which clearly has an object in range, and at the same time, the sound of the tone playing on the speaker (using the built-in tone() function) becomes distorted so that it doesn’t even sound like a square wave anymore. I’ve never experienced that before, and I have no idea what’s wrong there. Oh well, she looks cool aligning herself half of the time.

Fun game to play: See how many inconsistencies there are in this video. It’s a combination of videos recorded 7 months apart.

It actually works! Well, its first ever print-out could certainly do with some improvements, but to be honest, I’m happy it’s even intelligible at all! Part 7 in my super-basic, Arduino-controlled printer project.

[Watch in HD]

It should be better when I at least have a stable and level tray for the paper (or whatever) to sit on. I have an idea for an alternative to a heavy sheet of steel, which you should be able to see in the next video. Perhaps the PSU fan will have arrived by then, too… <_<

Also, enjoy the in-sync 50 FPS if you can! That pen flicks back and forth at stupid speeds, so a high frame rate is actually useful here.

Time for some real progress this time! The sixth part in this series where I make a super-basic printer with an Arduino.

[Watch in HD]

It’s pretty much ready to print – just a little hot glue and a sheet of paper and it’s all set! But unfortunately, this video is already ~8 minutes long, so that’ll have to wait.

After trying out solenoids and ruling out floppy drive motors because of speed, I looked at servos as a way of moving the pen up and down. I settled on Hitec’s second-fastest micro servo, which is digital (means it’s not limited to 50 Hz update intervals) and has metal gears (means it won’t destroy itself quickly). It’s designed for use in R/C helicopters, so I’m hoping this will handle the fast motions over a small range of travel, with a light load, well. I’m certainly impressed by it so far.

The most boring video in this series of me making a super-basic, Arduino-controlled printer. I made it at 50 FPS to try to make it more interesting to people who can play that, but that ended up making it out-of-sync at times. *Sigh*

[Watch in HD]

This is what happens when I don’t plan everything through before I start making something (i.e. all the time). Sorry. Stuff will actually happen in the next one, I promise!

Part four in this series of “making of” videos where I make a super-basic printer controlled by an Arduino.

There’s still no pen, so I stuck an LED where the pen will go and made it turn on when the pen should be drawing, as a test. Then, I took a long-exposure photo while it “printed” with the LED, pointing the camera upwards slightly after it finished each row. What I ended up with was a photo of the image that it tried to print, with inverted colours and stretched a bit because I didn’t move the camera at the right speed.

[Watch in HD]

It can also now print bidirectionally, and it’s much faster to receive the data for the next row of pixels, because they’re no longer sent one at a time.

Illustrations are by とんぐ (Tongu) and CAFFEIN (blog / Pixiv).