I'd like to introduce Processing to those who have not heard of it yet. It is a programming environment and language which shields you from the "annoying little details" of programming.
You can just jump in with little or no programming experience and have a GUI, 3D or a network application up and running in no time.
The Arduino development environment is based on the Processing environment. Which is why I thought it would be a good idea to check out Processing.. and I love it :)
It's probably the best way to learn programming... then again, you will probably end up hating all other development environments if you are used to the ease of Processing ;)
The BBox Drum Generator is an Arduino-based Midi sequencer mounted inside a Banana Box. The BBox contains a few preset drumbeats. These drumbeats form the basis for a drum variation algorithm (explained here). The amount of introduced variations is controlled by the blue rotary knob.
I've created four pushbuttons by mounting LEDs on top of PCB mounted mini pushbuttons. This idea is based on this article.
The two top buttons navigate through the functions of the BBox. The two lower buttons change the value of the function. Currently only the BPM and the Drum Preset can be changed.
The BBox only generates midi messages, the sound is generated by a Roland Juno-D.
The context I've been experimenting a bit with the Arduino as a basic midi sequencer. A drum sequencer is a good place to start. It's easier than an actual melodic music sequencer. You can leave out the length of a note, as a drum is a one-shot sounds device.
Because allowing the user to program drum sequences himself requires an extensive interface, or a piece of software, I thought I would write a drum generator.
Wouldn't it be cool if you can just push a button and a computer/chip does the whole creative process for you?
Yes, it would. But it scares me a little bit as well.
I've started with a mechanism that chopped up existing drum sequences in pieces and reassembles them to generate new drum sequences. This could work for breakbeat style drum patterns, but most of the time it seemed to create a build up of expectations, only to leave the listener behind with an empty feeling.
The drum sequence format Because the format in which the drum sequence is saved on the Arduino is essential to the Drum Variation Algorithm, I will explain this first.
The size of the RAM memory of the Arduino (based on an Atmega168) is small. Really small. Only 1kB. 1024 bytes. 8192 ones and zeros.
I'll just pause here for a while to let this sink in, I suggest you do the same.
Alright, if I want to use lots of data structures, I will have to make them small. The best way to make data small, is to assume as much as you can about the data in question and limit the possibilities as much as possible. So I introduced three limitations.
The drum pattern has a maximal resolution of 16th notes
For one instrument, the maximal number of notes that can be played in one measure is 16
There are only four velocity levels
Midi allows 128 velocity levels, I've made a mapping from 0, 1, 2, 3 to 0, 40, 90, 110 respectively (off, soft, medium, hard)
A measure consists of a maximum of three instruments
A typical measure consists of a hi-hat, a snare and a bassdrum, but which instruments are used is configurable
So if a measure has sixteen notes with four velocity levels, one measure for one instrument can be encoded in 4 bytes.
This is a typical drum notation which is used a lot online. I've used large and small X's to indicate the velocity level.
In the datastructure I've described above, this would look something like this. (A B in front of ones and zeros is the binary representation of a number: 11 = B1011 = 0xB)
The first number defines the instrument as a midi note number. 42 is a hihat, 40 a snare drum and 36 a bass drum. The total amount of bytes needed to encode a measure of 3 instruments with a maximal resolution of 16th notes requires ... 15 bytes.
A clearer representation would be a number in base 4, but afaik this is not possible in C/C++. B11001000 would be 3020, so a hard hit on the first 16th note, nothing on the second, a medium hit on the third and nothing on the fourth.
The Drum Variation Algorithm
If you've gotten this far, the algorithm itself is actually really simple, I hope it is not too much of a let down. If it is, I will gladly remind you of Occam's Razor.
Everytime a new measure starts, each byte of the datastructure (except the instrument note numbers) is bitwise XOR'ed with a random byte (a number between 0 and 256). The actual random number being calculated is one between 0 and a variable limit [controlled by a potmeter]. If the number is greater than 255, the original byte is left alone. With this you can control the amount of introduced variations.
Why bitwise XOR? It seems good at keeping the feel of the original pattern. It introduces new notes, but an XOR is also affected by the original byte. A bitwise OR can only add notes and a bitwise AND can only take them away.
Here is a video demonstrating the algorithm, the knob controls the amount of introduced variations (it also demonstrates the BBox Drum Generator, a post about this will be here soon).
"Wait, what? And you are writing a post about that?"
Ok ok, not very spectacular. I agree. But I replaced the broken red LED with a blue one! Still not excited? Ok, you may leave.
For the rest of you, here is a picture.
For those that are interested: the scroll wheel works with an infrared emitter and receiver. The infrared light is blocked and unblocked for every scroll "click". I did not know this, so I thought I'd share it with you. To be honest, I never really gave it any thought..
For people that like salvaging parts, here is a list of parts you can probably salvage from a broken optical mouse:
Several pushbuttons
A tiny camera with crappy resolution
Infrared receiver and emitter
An LED.. :)
USB cable [with one half missing]
Some chips, but I'm not sure if they will be helpful, or if you will be able to find datasheets
Mind you, it's a broken mouse. So some parts may not work :D
I've fiddled with midi and an Arduino before, but now I have integrated an LCD as well. Which makes the whole thing almost usable !
The Arduino makes everything really easy; it has tutorials about communicating with the LCD, there are forumposts where people explain how they hooked it up to midi. It really is just a matter of putting all the elements together.
Currently, the "Arduino Midi Sequencer" only plays a simple drumbeat (with adjustable BPM). I hope to make it a programmable sequencer by adding some buttons and interfacing with some permanent storage. If that doesn't work out, I'll just make it a pre-programmed drum sequencer, which can lay down the groove while I practice guitar and/or bass :)
Someone made a robot that searches for a "beatable object". When the robot finds this object, it lays down a funky groove ... and I think it's brilliant.
If you want to make a Qt application capable of serial communication with an Arduino, then these are some great resources to do so: * QextSerialPort : cross-platform serial port library * Arduino Serial reference : awesome Arduino documentation
Notes:
I had some trouble getting the QextSerialPort library to work with VS 2008, so I will just go over all steps I needed to take. * Run this command in the QextSerialPort directory: qmake -tp vc : this will make a .vcproj file from the .pro file * Open the .vcproj file with VS 2008 * Change the configuration type from dynamic library to static library [as the original setting did not produce a .lib file]
Add OGRE_HOME to the environment variables: e.g. OGRE_HOME=C:\OgreSDK
A Qt/Ogre project in VS 2008 Express
You will need a few .pro files setting up your Qt/Ogre project. It can all be placed into one file, but it might be convenient to split it into several files for easier reuse.
Settings.pro : Change your ogre home directory
win32 { # You may need to change this include directory OGREHOME = C:\OgreSDK Release:LIBS += -L$$OGREHOME\bin\release Debug:LIBS += -L$$OGREHOME\bin\debug LIBS += -L$$OGREHOME\lib INCLUDEPATH += $$OGREHOME\include }
For each project a separate project file. MyProject.pro : the sources and headers need to be edited, obviously
Now we set up the actual Visual Studio project: File->New Project->Visual C++ ->General->Makefile Project Go to the project properties (for All Configurations): Configuration Properties -> NMake -> General
This will tell your Visual Studio to use qmake, which will convert the .pro files to a makefile for nmake, and to compile this file with nmake.
Qt/Ogre IntelliSense setup
Go to the project properties (for All Configurations): Configuration Properties -> NMake -> IntelliSense
Common Language Runtime Support
Common Language Runtime Support (/clr)
Include search path
"$(QTDIR)\include";"$(OGRE_HOME)\include"
An OgreWidget implementation
I've tried to create a very basic OgreWidget which subclasses a QWidget. Most of the code was taken from a couple of the sources below, taking only the parts which are strictly necessary and leaving out all redundant code. The widget only renders the Ogre scene, it does not handle any user input. OgreWidget.h OgreWidget.cpp
Here is a code snippet on how to use this OgreWidget: In a QMainWindow:
m_pWidget = new QtOgre::OgreWidget(this); //Add the widget to the QMainWindow setCentralWidget(m_pWidget); //uncomment code below for fullscreen //Hide all the GUI stuff you do not want to see fullscreen /*menuBar()->hide(); statusBar()->hide(); showFullScreen();*/
Easy, isn't it?
Now you set up the Ogre scene:
//Create the scene manager mSceneManager = Ogre::Root::getSingleton().createSceneManager(Ogre::ST_GENERIC, "GenericSceneManager"); //Create the camera mCamera = mSceneManager->createCamera("Cam"); //Add a viewport to the render window from the OgreWidget m_pWidget->renderWindow()->addViewport(mCamera);
Of course your Ogre code will become much more ellaborate, but this is the minimum you need to render an Ogre scene inside a Qt Window.
I made this as another gift to a friend of mine, namely the drummer in my band (Skybluepink). It is a frame with the name of the band and two blinking leds behind it. It has an on/off switch and it runs on a 9V battery. Yes, it's not very high tech.
Score and Snap-method One of the difficult parts in creating this, was transforming a broken piece of plexiglass I found somewhere, into the shapes I needed for this object. As it turns out, using an ironsaw is a very bad idea. The best results I got, was by scoring it with a cutterknife a couple of times and then snapping it along the groove made by the knife, hoping that it did not snap in the wrong places :)
Spray-painting The other difficult part was the painting of the plexiglass. My buddy JD created a drawing which I cut out from a transparency sheet. I placed this shape over the plexiglass and then I spray-painted it. The problem was that a bit of the paint went under the cut-out shape, causing a lot of work the manually remove the excess paint. The best way to prevent this, is to make sure that the shape will not bend and is completely taped to the surface you are spray-painting.
Yesterday my Arduino microcontroller arrived by mail!
I used the class notes from this blog to get started. And 2 to 3 hours later, I made the video below. The arduino controls 7 blue LEDs [and yes, those are just straws on top of the LEDs] and animates them in many different ways. A potentiometer controls the speed of the animations. The Arduino makes everything really easy, it comes with software in which you can program the controller with a C-like language.
It has 8kB of Flash program memory, 1kB of RAM and a clockspeed of 12MHz. It has 13 digital in/out pins and 5 analog in pins. Analog output can be done with PWM [pulse-width modulation].
Below is a picture of the setup. The digital pins and ground of the Arduino are connected to the LEDs, the analog-in pin, the 5V and the ground to the potentiometer.
I made this effect for a friend of mine. We call him Schuif. Hence the name of the effect.
It is basicly a Fuzz Face. A good explanation of the technology of the Fuzz Face, can be found here.
I've added two LED's to this effect. They are used to indicate four modes of operation.
00: The effect is off
11: The effect is on, like a normal Fuzz Face
10: The effect is on, and an additional low-pass filter is added to the effect.
01: The effect is on, and an extra [germanium] diode from the signal ouput to the ground is added to the effect. It generates a very asymmetric signal, sounds horrible if you try to play a chord through it. I like it :)
The LED's are manipulated by the two switches on the side.
[Yes, I took the Bass Fuzz apart to create this effect]
The Bass Fuzz, it's the first guitar effect I've ever made. I started with this one because it's just so simple! [And because I play the bass, obviously]
I based my work on this site. I also added the Dirt-pot after the transistor.
What it looks like.
Yes.. err.. well, remember it was the first one I made :)
Projectify? Is that even a word? No, it is not. I will use it as The act of turning some kind of desire into a project.
Why do you need to do that, then?
Mainly, to learn new things. Also, to fill in some other kind of need.
Can't you just do that without projects?
Well yes.. and no. A project is defined as follows: A planned endeavor, usually with a specific goal and accomplished in several steps or stages. When you have a goal, it is much easier to keep on doing it. The learning or the need itself as a goal usually just doesn't work that well.
Ok, so what kind of projects are we talking about?
Everything, anything. But most will be related to music, electronics and programming.
I'd like to introduce Processing to those who have not heard of it yet. It is a programming environment and language which shields you from the "annoying little details" of programming. 
