MeeBlip Anode “Italian Way”: monophonic synthesizer with OLED display (and an overclocking option)

Goooooood evening dear makers! (and, in this case, I hope also musicians! 😉 )

It’s toooooo much time that I work on my projects without new posts, and I apologize for this.

The fact is that I have -as you know- many activities in parallel to making open source *ware projects: my work (I work in the frame of space projects for artificial satellites, for example I uploaded a little part of me on JUNO, and especially on the Italian part of Juno: the JIRAM instrument), my music (I play in some bands, and I also produce a lot of solo music: check it out  and download all at ) … and obviously my family!!! 🙂

So, since time is short… and life is too short, let’s start.

We can start from this beautiful project: Meeblip Anode.

It is a great monophonic synthesizer based on ATMEGA32P, with a really great sound, very deep and powerful.

…Have a look to demos on Youtube for the proof of what I’m writing.

I loved the MeeBlip Anode sound from the first time I heard it. In Italy we call this feeling “Amore al primo ascolto”…. 😀

And to me, the greatest thing of MeeBlip Anode is that this incredible project is completely (hardware and software) open source!!! You can buy a pre-built one, but you can also self-produce it in order to play it with your band or to modify/hack it (or both the things, like me ! 😉 )

Well.  I obviously self-produced one prototype of Anode and I started to play it in my music projects, but I wanted to add some (in my opinion) important functionality to this great project.

The idea has been of my father Gualtiero which, looking me playing with Anode and modifying the position of potentiometers, said to me: “It sounds very good… but… in which way you know the values for potentiometers?”

Woooow, thanks dad! It was the idea: add a numerical/visual indication of pots values using a display. An OLED display (because the OLEDs don’t have the backlight regulation…so less electronics to add! 😉 ).

And I decided to call this mod “Italian Way” because in Italy we always need visual information. For example think to our famous gestures when we (try to) talk in English to tourists to give them indication on the streets of our cities. 😀

So, I decided to proceed in the following way:

  1. Look in the electronic schematic if ATMEGA32P has some free GPIO to be used in order to command the display (at minimum 6  pins, which is the minimum for commanding the great part of displays)
  2. Since the Meeblip code is written in AVR assembler, download and study the datasheet (and instruction set) of the ATMEGA32P. I was a good assembler programmer once upon a time…but now I am a little older, so… 😉
  3. Find a good AVR driver or set of subroutines for commanding display, written in assembler
  4. Decide which synth values to display on the OLED!
  5. Modify these subroutines in order to display in quasi-realtime, and integrate them in the original code
  6. Modify the original Meeblip code in order to use the display subroutines.

Well…the work has been long (long, long, very long and again looooooooong) and hard (hard, very hard… etc.).

But I think it has been a great work! 🙂

I uploaded all the code on GitHub. I dont know if I well done all the process, but this is the first time with GitHub for me…. 😉

For the project I realized a new branch from the official one. So you can download all my code from:

The GPIO pins to be used

I had been lucky: the MeeBlip Anode has some free (and not connected) GPIO on the microcontroller, so they can be freely used to command a display.

They are reported in the following photo:


I decided to use an OLED display by Newhaven ( Mouser code 763-NHD-0420DZW-AG5), which will use 4 pins for data (+ 2 pins for Enable and RS) chosen from PB0, PB1, PB2, PB3, PD2, PD5 and PD6 (plus 5V and GND).

The mapping used for the connection between  the display and the ATMEGA32P has been the following:

  • Display pin 1 (Vdd): VCC
  • Display pin 2 (Gnd): GND
  • Display pin 6 (data 0): PB0
  • Display pin 7 (data 1): PB1
  • Display pin 8 (data 2): PB2
  • Display pin 9 (data 3): PB3
  • Display pin 4 (RS): PD5
  • Display pin 5 (E): PD6

So… I solded the pins of ATMEGA32P to display pins using a 9 pins male/female connection (such as a simple serial connection). The result has been the following:


The datasheet and code study

Simple step…but very tricky! 🙂

Well, during this step I downloaded the Atmel Studio 6 (freely available) and I wrote some example code, I used the debug function on the simulator and then I created a project based on the Meeblip Anode original code downloaded from Github (and obvioulsy I succesfully recompiled it).

The display driver written in AVR assembler and his

I found a really good set of subroutines written in AVR assembler for ATMEGA328 (but it is working also on ATMEGA32P) to command displays using 4 wires. This is the complete code from which I started.

I created the file, and I added it to the Atmel Studio project. Obviously I changed the GPIO assignments in order to match to GPIOs used in my situation. I also added some modification regarding the fact that I would like to display values taken from the RAM of the microcontroller and not from the program memory (as is in the driver). This is the fundamental modification, at line 786 of file

;lpm     temp_lcd, Z+   ; ///ML: removed since this instruction read from Program Memory
ld    temp_lcd, Z+      ; ////ML: get a character from RAM

And I also added some ad-hoc subroutine to be used in the frame of the modified MeeBlip code. They are the main ones:

  • MYLCD_PREPARE_GUI is the subroutine which prepare the display inserting the fixed labels (they wont change during normal operation of synth).
  • MYLCD_UPDATE is the main subroutine used to refresh the display (pots values and switches status). It refreshes tha display on every 100 milliseconds.
  • MYLCD_CLEAR is used to clear all the display

Note also that in order to display numeric values in the display, a conversion between the values and his correspondent string should be done. For this I found online a very simple subroutine which is called in order to have the values to display in ascii format. This is the subroutine contained in the file

   ldi r18, -1 + '0' 
    inc r18 
    subi r16, 100 
    brcc _bcd1 
    ldi r17, 10 + '0' 
    dec r17 
    subi r16, -10 
    brcs _bcd2 
    sbci r16, -'0' 

Well…  now we can include and use the file inside the original MeeBlip code.

Synth values to display on the OLED

I chose to display the values directly tied to the potentiomenters position and to switches positions. But it is only an idea: you can decide to display also other parameters. 😉

In this hand-made drawing you can see the Anode panel with the names of global variables tied to pots and to switches.


Under each switch you can see the switch number to refer in the code. Under each potentiomenter (in the [] parentheses) you can see the name of the variables used to memorize the pot values.

Note that the pot on the bottom-left is used for two purposes (waveform and width), depending on the position of switch 3. The real variable names for this pot are the following (I know, the drawing is not updated to the last revision of my code…. but I loved to report it in my post 😉  ): WAVETABLE and PULSE_KNOB_LIMITED.

So in the code I managed this in order to display the right values depending on the siwtch position. You can see in file at the labels DISPLAY_WAVETABLE_VAL and DISPLAY_SWEEP_VAL. The choice of the path is done at lines 301 to 303, analyzing the current (and saved in a temporary variable) position of the switch 3.

The other variables names to display reported in the drawing should be OK…. I hope! In any case you can refer to the code, which ever says the truth! 🙂

Integration with Meeblip original code

I included the file after the inclusion of file “”.

I defined some variable in

///ML 20x4 lcd strings (4 rows of 20 chars+'\0')
my_LCDstring4: .byte 21
my_LCDstring3: .byte 21
my_LCDstring2: .byte 21
my_LCDstring1: .byte 21

//ML temporary variable in RAM
temp_in_RAM: .byte 1

After this, in the main program, the LCD is initialized using:

//---start delay routine
push r18
push r19
push r20
; Generated by delay loop calculator
; at
; Delay 8 000 000 cycles
; 500ms at 16.0 MHz

    ldi  r18, 41
    ldi  r19, 150
    ldi  r20, 128
L1: dec  r20
    brne L1
    dec  r19
    brne L1
    dec  r18
    brne L1

pop r20
pop r19
pop r18
//----end wait routine---
//prepare LCD gui (not to be refreshed at each basic cycle!)

Then, the display refresh routine is called at each cpu cycle using:


Note that, since the memory occupation has been increased, I had modified  some “rcall” instruction in “call”. You will find these changes searching for this comment:

//ML--->>changed rcall in call to avoid error " relative branch out of reach"

Well, that’s (mainly all)!

Recompiling the code and burning the binary on the ATMEGA32P you should obtain (after a screen reporting the name and the version of the synth) something like this:


I’m sorry for the bad picture…but I was so excited! 🙂

The tests using the synth have been all successful, that is:

  • MIDI IN is OK (no MIDI note is lost during play)
  • Audio is OK (the notes produced with the working display have the same waveforms of them produced by the original Meeblip Anode firmware, I tested it with oscilloscope)
  • The interaction with the pots and switches are OK (the refresh of values on the display is very fast respect to the actions on the pots and switches).

So…it seems that a refresh rate of 100 milliseconds should be a good choice for ATMEGA32P computational load!

This is my MeeBlip Anode “Italian Way”, and now, after this great ordeal, I am ready for a (big) glass of Italian grappa. 🙂

I recall here the link to the code in GitHub:

…Bonus Easter Egg (for die-hard geeks only): overclock it!

I am an old style geek… some years ago one of my hobbies was to overclock the CPUs of my computers.

I know that ATMEGA32P can be connected to a crystal with maximum frequency of 16Mhz (following the datasheet). But…I love the risk (hmmmm…. only on electronics things! 😉 ) so I wanted to connect him to a 20Mhz crystal.

With some basic code modification, you can have your overclocked Meeblip Anode “Italian Way”.

These are the modifications.

Firstly in the anode.asm file we change the cpu frequency:

.SET cpu_frequency = 20000000 //ML changed the CPU frequncy to 20Mhz

The other basic modification is the Timer 0  initilization (which is the hearth of the MeeBlip sound generation):

;initialize Timer0:

      //ldi     r16, 49             ;\  ; Set sample rate to 40.00 kHz //ML---> commented, since we need a new prescaler value
      ldi     r16, 62                ;\  ; Set sample rate to 40.00 kHz: ML---> we use 62 if the clock is 20Mhz since 16Mhz:49=20Mhz:x... in this case we have always the note in tune!
      out     OCr0, r16           ;/ OCr0 = 49 (///ML---> 62 on overclocked version) gives 40000.00 Hz sample rate at 400 cycles per sample loop.
      ldi     r16, 0x0A           ;\ clear timer on compare,
      out     TCCr0, r16          ;/ set prescaler = CK/8

Note that I used the value 62 for r16, instead of theoretically correct value 61, since I used a software tuner to have the best sound (Tunafish for MacOSX) and trying the values around 61.
Then I add a warning also in the initialization of Timer 2 PWM controlling cutoff…

ldi      r16, 0b01100001     ; Phase correct PWM, no prescaler ///ML WARNING: verify if the soud is nice with 20Mhz clock, else adjust!!!

For me the sound is nice…. 😉

In the file you should finally set the new frequency:

.equ    fclk      = 20000000      ;///ML---->new  system clock frequency (for delays)

This should be all for this easter egg… but I think you should do many other improvements of the code!

I had no problem and I played (and I’m playing) with great satisfaction the overclocked synth in my home studio for several projects…. but note that nothing is guaranteed with this mod. So handle with care! 😀


Phhhhhheeeeewww (I can rebreath now :-D)….Well geek boys & girls, that’s really all for this time.

It was a long time without a post on Garretlabs, but with this one I think I paid my debt with DIY community and to Garretlabs readers!

Bye bye folks… and keep always in touch with Garretlabs!


My experience with!

Goooood morning Internet (of things sure, but overall of human beings and nerd people)!

This time I would like to talk briefly about the very good experience that I had using the PCBWay ( online service for my PCB production.

All started when I decided, some years ago, to start producing on myself the PCBs for some of my projects . But I don’t like home-made results, so I looked for a great time for a very professional online service, with low prices and great quality. Mhhhh….difficult task! 😉

After a long discussion, a work colleague (the Brain of the well known italian site recommended to try the service, because, he said, “the price of PCBWay is the best on the Internet”.

So…I tried it with a free online quotation…and I saw he was right (and I was sure of this). 🙂

No problem, I had at that time a project waiting to be produced so, I tried PCBWay. And I was super-satisfied. No joke boys (and girls).

This company works very well, with very small prices and great quality of produced PCBs.

The site has a very simple interface and the files used by PCBWay for production are the standard Gerber and Excellon files produced by Eagle, Kicad etc.

Well, the production time is very (very) short, 3-4 days …and the delivery time from PCB Way to my house (as you know I’m from Italy) is shorter than a standard packet from my city to another italian city using (express) Italian Postal Service (Paccocelere Poste Italiane). 🙂

….Obviously, since they use DHL as express courier… all it’s guaranteed. 😉

You can see here some of PCBs produced for me by PCBWay (sorry for the not so good quality of photos). All boards that I produced are on 2 layers, and I used  various colors. All produced boards have been excellent!




I’m very satisfied with this company, so I recommend it to all you my dear geeks!

Bye bye…. and…in the next days I will publish a surprise, so keep in touch! 😉

I’m not dead. I’m only (terribly) busy! :-(

Hi techo girls and boys!
I know…I know.
It’s more than one year that I don’t publish new posts on Garretlabs.
The fact is tied to new engagements: on the work (yes, I have a work which is very important to me and I want do the best on it…), in the frame of my family.
And I have also (of course) new musical projects,as composer and musician (please,check out my italian music site, and dowload for free all my compositions: but also as project engineer  and producer of noise machines and analog and digital synthesizers.
For example, for the friend Stefano Muscas of great band “Correlazione quantistica” (please, visit the facebook page: I designed an produced a very interesting noise machine based on Arduino, called ALGOnoise.


I took the idea from here: but I added some modification (a repetition function, an output amplifier and some funny values changes on the resistors). I will publish very soon the result on Garretlabs (I hope)!
Here you can see a live concert of Correlazione Quantistica with Stefano playing ALGOnoise (yes, it’s the yellow box 🙂 ):




I’m very honoured of this collaboration!
After this I produced a modified version (the modification are: all controllers are panel mounted, the on-off button can be bypassed by a switch pedal, double resonance potentiometer and an adapter for the use with a power supplier) of the well known SparkPunk by Sparkfun. I did it for my friend Alessandro “Mazza”, the singer of the historical italian demential-metal band Tossic (
Here you can see the naked machine called “Mazzulator”:


I’m very excited to work with Alessandro, since I love his band from ever. I was 14 when I encountered for the first time the politically uncorrect world of heavy metal, and the first disc I listened was “Il Regno del Cingliale” of a strange and demential band called Tossic: one of the first italian heavy metal bands. Now I am 40, an d I love Tossic as the first day. 😉

Well… after this I produced some other music/noise machines, especially guitar effects pedals For example, I built an echo/delay and a chorus pedals for my friend and guitar player Fabiano Vezzosi, and I modified a model of the well known pedal “Metal Zone” (by Boss) in order to transform this pedal in a great fuzz effect. It kicks asses now! 😉

I also modified a great number of other guitar pedals of many friends…But in the meantime I produced also some other interesting things: for example new versions of old (diy) synthesizers. :-O

…But it is another story: keep in touch to discover this “dark side of Garretlabs”. 🙂

…and now ANOTHER music post: SparkPunk Sequencer MIDI synchronisation with Arduino (work in progress)

“Tunz-tunz-tunz” 😀 my dear geek-musician friends (female and male of course)!

Today I used for you my “house-disco-techno”-style “hello”, because today I wan t to talk you about msuica (again).

Some day ago I bought from my preferred store (RobotItaly, as you know), and I assembled two new exciting toys from Sparkfun: Sparkpunk Sound Generator and SparkPunk Sequencer.

The Sparkpunk Sound generator is a very interesting sound generator similar to the famous ATARI Punk Console,  The Sparkpunk Sequencer is a control voltage step sequencer used to control the the Sound Generator.

After the assembly of the two devices, I played some hour with these objects… but, as you know, I am a (pro-am) musician, and I would like to have a MIDI IN  port in all my instruments. Because I attach my devices to my DAW (digital audio workstation, examples are: Steinberg Cubase, Ableton Live, Cakewalk Sonar, Apple Logic Pro etc.) resident on my computers (Mac or PCs), and my DAW  is ALWAYS the MIDI master for my set of instruments. I should command the tempo, the start and stop of my devices.

Before to do my modifications, I printed (and read) the following IMPORTANT page: . So, firstly I followed the steps for modifications in the section “Synchronizing Multiple Sequencers” and I opened the connections between IN and OUT for the pins CLK, BTN, RUN, STOP (and I used jumpers in order to re-close them again, in case the sequencer isn’t controlled from another device and it used stand alone).

After this, I thinked to use an Arduino UNO as interface between my MIDI master (the DAW) and the Sparkpunk Sequencer in order to force the Sparkpunk Sequencer to follow the MIDI clock of the DAW. This is the actual setup of my experiment:


Well, the PC (Midi OUT port) to Arduino (MIDI IN port) is not difficult: it’s a very simple circuit described in one of my old posts. Using this setup the MIDI in signal pin will be connected to the Arduino D10 pin via SoftSerial.

In order to build logicaly and electrically the interface between Arduino and the SparkPunk Sequencer I studied the signals on the CLK IN, BTN IN, RUN IN, STOP IN pins in the Sequencer stand-alone configuration (so the CLK IN is connected to CLK OUT, BTN IN is connected to BTN OUT, RUN IN is connected to RUN OUT and STOP IN is connected to STOP OUT… using my preferred tools: the jumpers!).

I studied them connectinfg the oscilloscope on the pins and pressing the Run button on the Sequencer in order to start and stop the sequence. These are the results (drawn by hand… it’s so stylish and vintage! 🙂 ):

wpid-storageemulated0DCIMCamera2014-10-21-07.58.15.png.pngWell… as you see the behavior is very simple. And we can simply replicate it using Arduino with the following logic:

  • When Arduino receives from DAW the MIDI START message it commands the RUN IN pin high, the STOP IN pin  low and BTN IN pin firstly high and after a short delay (I used 5ms and it works…but you can measure the real value with the oscilloscope if you want) it commands it again low.
  • When Arduino receives from DAW the MIDI STOP message it commands the RUN IN pin low, the STOP IN pin high and BTN IN pin firstly high and after a short delay (I used 5ms and it works…but you can measure the real value with the oscilloscope if you want) it commands it again low.
  • The CLK IN value is commanded by Arduino following the reception of the MIDI CLK message, in order to synchronize the tempo of Sparkpunk Sequencer with the DAW tempo.

IMPORTANT Note: a standard MIDI CLK message is sent by a DAW 24 times per quarter note. A time of 120 BPM (beats per minute) is equivalent to 120 quarter notes per minute, so in this case the DAW sends from the MIDI out (120*24)/60 messages per second. It’s too much for our Sparkpunk sequencer (if you sends all these messages to ther sequencer, it doesn’t work…and you can’t see the ON/OFF of the Rate led).

So I decided to send to the SparkPunk sequencer only one MIDI CLK message per 24 received by the MIDI IN port on Arduino. In other words Arduino decreases the rate of MIDI CLK message in order to correctly command the sequencer.

Regarding the hardware connections, the are very simple:

  • Connect the Arduino GND to a GND point of the Sparkpunk system (i.e. the ground of the Speaker port on the Sound Generator)
  • Connect the Arduino pin D2 to the RUN IN of Sparkpunk sequencer
  • Connect the Arduino pin D3 to the STOP IN of Sparkpunk sequencer
  • Connect the Arduino pin D4 to the CLK IN of Sparkpunk sequencer
  • Connect the Arduino pin D5 to the BTN IN of Sparkpunk sequencer

This is the simple Arduino code:

#include <SoftwareSerial.h>
SoftwareSerial MidiSerial(10, 11); // RX, TX

byte midi_start = 0xfa; 
byte midi_stop = 0xfc; 
byte midi_clock = 0xf8; 
byte midi_continue = 0xfb; 
int play_flag = 0;
byte data;

//synchro values
int number_of_received_clocks=0;

#define MAX_BPM 160
#define MIN_BPM 20

void setup() 
  //led 13 used for debug
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
  //interface --->Sparkpunk sequencer
  digitalWrite(2,LOW); //midi start sequencer
  //interface --->Sparkpunk sequencer
  digitalWrite(4,LOW); //midi synch sequencer
  //interface --->Sparkpunk sequencer
  digitalWrite(3,HIGH); //midi stop sequencer
  //interface --->Sparkpunk sequencer
  digitalWrite(5,LOW); //button sequencer 

void loop() 
  if(MidiSerial.available() > 0) 
    data =;
     if(data == midi_start) {
       Serial.println("Start Midi");
       //sparkpunk interface commands
       digitalWrite(2,HIGH);//start/run sequencer
       digitalWrite(3,LOW);//stop sequencer
       digitalWrite(5,HIGH);//button sequencer
       digitalWrite(5,LOW);//button sequencer
       play_flag = 1;
      else if(data == midi_continue) 
        play_flag = 1;
      else if(data == midi_stop) {
        Serial.println("Stop Midi");
       digitalWrite(2,LOW);//start/run sequencer
       digitalWrite(3,HIGH);//stop sequencer
       digitalWrite(5,HIGH);//button sequencer
       digitalWrite(5,LOW);//button sequencer
        play_flag = 0;
      else if((data == midi_clock) && (play_flag == 1)) { 
        if(number_of_received_clocks%24==0) //see MIDI specification: the clock is sent 24 times for quarter note, and 120BMP=120 quarter notes for minute => BPM value= 60/time to receive 24 clocks

void Sync() {
     digitalWrite(4, HIGH);
     delay(100); //high part of the clock square wave.
     digitalWrite(4, LOW);

As you see I used for the CLK IN  a square wave with a period of 200 ms (100 ms high and 100 ms low). It seems sufficient in order to command the step ahead of the sequence.

Ok, using this sketch and starting the MIDI clock on my DAW, the Sparkpunk Sequencer starts working, exactly synchronized with the DAW (and the sound is correctly generated by the Sound Generator). Modifying the BPM tempo on the DAW causes that Sparkpunk SEquencer changes correctly his tempo, and it correctly starts/stopswhen the start/stop command is sent by the DAW. Yeahhhhhhhhh! 😉


Yes, there are always some “But” in my projects. 🙂

In this case there are still some strange behaviors of the system, to be investigated and debugged (also with YOUR contribution, my dear followers, if you want):

  1.  The Sequencer start working also if the POWER switch is OFF, and at the same time the . It’s clear that the sequencer and sound module takes power from the 4 pins connected to Arduino…
  2. In this condition the ouput volume of the Sound Generator is a little low… maybe the Arduino doesn’t drive the correct power supply to all the system. 😦
  3. In this condition (POWER switched OFF) only the LONG pulse works, if I switch on SHORT no sound is emitted from the Sound Generator.
  4. If I change the POWER switch from OFF to ON on the sequencer (or on the Sound Generator), only the SHORT pulse is emitted (if I switch to LONG pulse no sound is emitted)
  5. Finally, in this case (POWER switched ON on the Sequencer) the output volume of the Sound Genrator is higher.

I think all is tied to the fact that Arduino power is not sufficient to drive all the circuits (Arduino itself+MIDI interface, Sound Generator and Sequencer), and to the fact that Arduino uses 5V as HIGH value for the CLK IN, but Sparkpunk sequencer uses 7.5V. See also the paragraph called “Switch Voltage Processing” in the …I think it is very involved in this behavior of the circuit. I’m continuing my investigation.

Another solution I would try in the near step of my experiment is to use a MOSFET commanded by Arduino pin D5 (connecting the D5 to the gate pin, the CLK IN to the source pin and the CLOCK OUT to the drain pin, for example), in order to control the synch pulse on the CLK IN connecting it to the CLK OUT (something similar to a electronic switch), in order to have the same situation of the stand alone Sequencer configuration, but generating the clock pulses using the MIDI tempo. It’s a solution similar to which used in this video from Sparkfun:

Well… but now, after this ordeal, I’m really ready for a glass (…a bottle?) of my preferred grappa. If you know what I mean. 😉

Bye bye daft-punk-electronicmusicians-techno friends!


Garretlabs meets Bleep Drum: an Arduino based drum machine with some “tasty hacks”!

Hi techno girls and techno boys!

A long time is passed from my last post, but I worked to many projects in parallel… some of these will pe published here in the near (…ehhhhmmmm!) future. 😉

Since you know I am also a musician (please visit my italian music homepage, which contains  good music to download 😉 :, today I present you a very interesting “hack” which I’ve done starting from a beautiful device from Bleep Labs: the famous, open source and open hardware, and overall groovy Bleep Drum (a very powerful drum machine with a set of 80’s sounds):

The great Bleep Drum with MIDI controller

I asked Dr. Bleep (the Bleep Labs boss) the permission to publish here my complete hacking project….and he gave it to me with pleasure. Many thanks Dr. Bleep, you’re a great!

…So, I am here to describe you my work.

Starting from the schematic of Bleep Drum I noticed that the device used one ATMEGA 328 with 16Mhz quartz….very similar to Arduino architecture.

Then I downloaded the source code (version 07)  for Bleep Drum from the official repository…and I saw that the code was written for Arduino! 🙂 . Note the newest version of the software is the 09.

So, I replicated the embedded project using and Arduino Uno (using the well known mapping between Arduino GPIO pins and the ATMEGA328 pins) and two/three breadboards in order to apply my hacks.

Well, I wanted to add three main functionalities to Bleep Drum:

  1. A two channels-mon0 output instead the original one channel mono (because in my home studio I would like to use the output of the Bleep Drum to enter in two mono parallel filters)
  2. A Volume control
  3. A little amplification functionality

So, I worked on the output stage of the Bleep Drum and I applied the following modifications (all is designed “by hand”, as usual! 😉 ). In the drawing (made by ML 🙂 ) you can see the differences from my output stage and the original one.


In practice, I directly connected the output of the MPC4901 DAC to a LM358 dual operational amp, removing the resistor and the capacitor and adding a 10K potentiometer in order to control the volume.

I connected this output to the two gates of the LM358, in order to have two amplified mono channels.

Finally,  as you see,  I’ve connected the two outputs of the  LM358 gates to the jack tip and ring using two 10uF capacitors.

This is the complete Fritzing schema of the project (click to view the full size image).

BleepDrumsML_v04---FINAL---amplified+stereo_bbThis is the overall project photo:


And finally, thi is the detail of the modified output stage:


Regarding the Arduino software, the version 07 of the official sofware is working great on my hack! 😉

Now the output of my homemade Bleep Drum is very loud (and also “pumping”, if you know what I mean 😉 ), controlled in volume and on two mono channels. YEAHHHHHH! 🙂 So…I will use this instrument in my next electronic music compositions… because (as many of you know) I love the 80’s sounds!

Before to close this post I would like to thank again Dr. Bleep (and Bleep Labs) for his great work and for his helpfulness.

Bye bye geek-girls and geek-boys: I go to compose some good music…using my new instrument! 😉

See you soon!


MIDin: a trasmitter/receiver sytem for MIDI messages using XBee and Arduino

Hi hi-tech friends (…with a prominent geek attitude 🙂 )!

This time I would like to talk about…MUSIC! Ta-daaaa!!

As you know I am also a musician, and I produce freely downloadable music from my music website (only italian language, sorry!  ).

I have a large set of keyboards and synthesizers in my studio, and I have also a Roland AX-7, a “wearable” MIDI controller keyboard similar to a guitar (today these instruments are called “keytars” 😉 ). This keytar is used also by the mighty Herbie Hancock…. 😉

This keytar has also a great feature: it can be power by 6 AA batteries….but you will have always the midi cable in order to command your sound generator or expander (or software synth etc.). The midi cable is a limitation to your performance freedom on stage…so I want to cut it! 😉

There are some good wireless solution off-the-shelf, for example the Mid-Air product from M-Audio….and the price is not so low. 😦

…So I want to realize a DIY solution, using two Arduinos UNO, two XBee Shields and two XBee modules: this is the Garretlabs MIDin project! Ta-daaaa!

I bought from my preferred store ( the following components:

Then I connected these components to two Arduino UNO boards in order to realize: one component working as MIDI Receiver-XBee Sender and one component working as MIDI Sender-XBee Receiver.

Thi is the system overview…design handmade by ML! 😉


First step: program the XBee modules

This is the more complex step…I don’t love it but (unfortunately) it is necessary.

We must to setup the Series 2 modules in order to enable the “AT mode” communication (the Series 2 chips support also another -more complicated- configuration, in order to realize very complex networks of XBee modules). In other words, we must to program the devices in order to simulate a point-to-point-connection, a true serial wireless connection.

The best tutorial I’ve found on the internet is the following: I used it step-by-step in order to configure my XBee modules…and it worked great! 😉

Firstly I downloaded  and installed the X-CTU utility (only for Windows… 😦 ) from Digi site.

After this, I attached a wire to the RESET pin of the Arduino and I connected it to GND. Then I connected the XBee Shield with the XBee module onboard (remember to set his jumper on “USB”): this is the way to directly access the XBee modules for programming them using Arduino board USB connection. In other words, to program the XBee modules it’necessary to disable the ATMEGA chip, so…or you remove it, or you connect to GND the RST Arduino pin. 😉

So, I used as network ID the suggested number (1234), then I configured one module as Coordinator AT (setting in the values SH/SL of  serial number of Router module), and I configured the other module as Router AT (setting in the values SH/SL of Serial Number of Coordinator module).

Well, once configured, the two modules start to “talk” each other, and the leds on shields start to blink. To test the correct configuration you can use the procedure well explained in the

IMPORTANT NOTE: I used the default speed of serial connection (9600 bps) for XBee modules, since I noticed that if I change the data speed, the USB connection from Arduino IDE to Arduino in order to download applications should fatally fail.


Second step: the MIDI receiver-XBee sender

The difficult step is passed…so, one moment of relax now! 😉

Ok, let’s start with the secdond step.

This MIDI receiver/XBee Sender has one MIDI connector in order to receive MIDI signals from a synthesizer, the software collect them, then it uses the XBee serial link to send MIDI signals to the other system component (see the third step).

The circuit is very simple…. and it is based on the standard MIDI-IN circuit. See to see the details. I modified it a little (especially the optocoupler)…in order to match the parts I had in the “Garret” at the moment 😉 !

The components are:

  • 1x Optocoupler 4N35
  • 1x Diode 4148
  • 1x 100KOhm resistor
  • 1x 220Ohm resistor
  • 1x 3.3KOhm resistor

Note that in the schema I added the XBee module and the XBee shield on the right side of Arduino, in order to better explain the connections, but OBVIOUSLY their must be mounted ON the Arduino! 🙂


The software is simply a MIDI messages collector and re-sender.

Note that I used a buffer to memorize a certain number of MIDI message before to send them, because if wen I receive a message I resend it immediately, I could loose another MIDI message incoming in the meantime. So, I used a “buffering approach”. I verified -as musician 🙂 – that the latency due to buffering is very (very) low, so this approach is acceptable. 😉

Note also that I use the Software Serial (the RX is on pin 10)  to receive MIDI messages, because XBee must use the Serial port.

 #include <SoftwareSerial.h>

SoftwareSerial MidiSerial(10, 11); // RX, TX

byte in_buffer[1024]; //maximum number of bytes arrived in one cpu cycle
unsigned int received_bytes;

void setup()
  Serial.begin(9600); //XBEE transmission
  MidiSerial.begin (31250); //MIDI transmission
  //led 13 used for debug
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);


void loop()
      for (int i=0;i<received_bytes;i++)
        in_buffer[i];  //save in the buffer all bytes arrived from MIDI port
      //write all bytes arrived in the present cycle (so, the input is decoupled from the output)
      digitalWrite(13, HIGH);
      for (int i=0;i<received_bytes;i++)
      digitalWrite(13, LOW);
      //reset the counter of received bytes in the cycle

In order to write the program on Arduino, you must set the XBee jumper on “USB” position (and obviously you must to remove the cable to ground connected to the RST pin…see step one!). After programming, you should set the jumper on “XBee” position.


Third step: the MIDI sender-XBee receiver

Well, this component is more simple than the previous: it receives the MIDI messages from Xbee serial wireless link and it resend them to the MIDI Out port, in order to command a sound generator, a expander or another synth.

Only one component in this case:

  • 1x 220Ohm resistor

This is the (simple) circuit. As you can note, the MIDI In and Out circuits are NOT mirrored (this is the standard)! ….What a strange design choice!!! 🙂



And this is the Arduino software (the MIDI management functions are taken from

#include <SoftwareSerial.h>

SoftwareSerial MidiSerial(10, 11); // RX, TX

void setup()
  Serial.begin(9600); //XBEE transmission
  MidiSerial.begin (31250); //MIDI transmission
  //led 13 used for debug
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);


void loop()
  if(Serial.available() > 0)
    digitalWrite(13, HIGH);
    MidiSerial.write(; //receives the midi messages via XBEE...and send it to Synth
    digitalWrite(13, LOW);
  //Test function

void SendAllNotes() {
  // play notes from F#-0 (0x1E) to F#-5 (0x5A):
  for (int note = 0x1E; note < 0x5A; note ++) {
    //Note on channel 1 (0x90), some note value (note), middle velocity (0x45):
    digitalWrite(13, HIGH);
    MIDICommand(0x90, note, 0x45);
    digitalWrite(13, LOW);
    //Note on channel 1 (0x90), some note value (note), silent velocity (0x00):
    MIDICommand(0x90, note, 0x00);   

//  Send a midi command.  Doesn't check to see that
//  cmd is greater than 127, or that data values are  less than 127:
void MIDICommand(int cmd, int pitch, int velocity) {

Now you can write the software on Arduino,

And…well… that’s done! 🙂

To test the system you can connect a master keyboard (better if it is a keytar! 😉 ) to Midi Receiver-XBee Sender and a sound generator to Xbee Receiver-Midi Sender…. and you can try to emulate Sandy Marton’s (one of my 80’s Italo Disco heroes) performances with their faboulous keytars!

This is the mighty Sandy in one of his mighty performances:


Well… it seems a DIY keytar!


Bye bye people, now I go to play some note with my AX7…I need a music overdose (I think today I will write an italo-disco song)! 😉

And…remember tio visit my music site!


Galileo, Galileo… and me.

…Gooooood morning people!!!

My name is Marco Lastri (ML), I am an italian pro system-software engineer and also a pro-am musician.

I work as software engineering manager in scientific areas tied to artificial satellites. I have approx. 25 years of experience in computer science, algorithms, architectures and programming (I started to program my first computer at 12)…and I play any kind of software and hardware synthesizer. And also a little of drums! 🙂

I am interested in the music-electronics-software interaction (because I am not a good piano player! 🙂 ), so I tried to study Arduino (Intel Galileo), Raspberry PI platform and some other ARM based boards in order to create projects often tied to wearable musical instruments (yes, I love all old-style “keytars” such as Moog Liberation!!! 🙂 ).

2014-02-24 07.45.14

So I decided to try this experience: a personal blog dedicated to my projects and to my ideas, based on open source hardware and software solutions.

…You will find here also tips’n’tricks found during my studies on these “black boxes” (damn’ lack of documentation!) called “embedded boards” !

This blog has been created in collaboration with the SirsLab of Università di Siena and with SirsLab official blog (many thanks to professors Domenico Prattichizzo and Monica Malvezzi), in order to share with the SirsLab people experiences on the wearable controller devices.

Firstly… why Arduino? Because it’s an italian product, an italian (good) idea. Because Italia is not only “spaghetti, pizza, mandolinoand corruption. 😉

…Why open source? Because I think it is the only way to create low price new ideas, also created by unexperienced people (but with great mental strenght!).

…Why an english blog? Beacuse, also if my english is poor, I think it’s a simpler way to share with the internet my ideas and my experience.

…Finally, why this blog is called “ML Garret Labs“? Because at the moment my lab is  in my garret…. 🙂

Bye bye tech-geeks…and stay tuned!

PS: in the photo with Galileo, Galileo and me…  there was also Figaro Magnifico (cit. Queen), but it was too on the right 🙂