Syslog

Since I am now starting the synth at boot time, all my logs are going to stdout and it is hard to figure out what is happening when things go wrong. Also printf seem to affect synth performance. For both those reasons, I decided to use syslog for my run time logs. This is what I did:

1. Initialized logs doing:

setlogmask (LOG_UPTO (LOG_DEBUG));

openlog ("mysynth", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER);

2. Replaced printfs with one of the following macro calls:

#define ERROR_LOG(...) \

    syslog(LOG_ERR, __VA_ARGS__)

#define INFO_LOG(...) \

    syslog(LOG_INFO, __VA_ARGS__)

#define WARNING_LOG(...) \

    syslog(LOG_WARNING, __VA_ARGS__)

Start Synth at boot time

In order to have my synth application start when booting the raspberry pi, I followed the instructions here and created an script in /etc/init.d and calling "sudo update-rc.d NameOfYourScript defaults" to register the script.

Jansson

I decided to use json to format the presets data to store. I have some experience using jansson c library for managing json files, so I decided to use the same here. Since jansson does not seem to be available in raspbian packages, I followed these steps to install it:

git clone git://github.com/akheron/jansson.git
cd jansson
sudo apt-get install autoconf
sudo apt-get install libtool
autoreconf -i
./configure
make
sudo make install
sudo ldconfig

Instructions coming from here.

Tools

Here are some tools I acquired for this particular project, which I hope to use often for now on and which I regret not having bought earlier:

1. Hot Glue Gun: I glued the screen to the case using this. Seems like the kind of thing that everyone should have at home.
2. Step Drill Bits: These are greats for making big diameter holes, for potentiometers or switches for example. If you do guitar stomp boxes or analog synths you need these, I regret not having bought them before, making big holes with small drilling bits is a pain. I got these from Dealextreme, here.
3. USBtinyISP: Already mentioned about this one here. This was a replacement for my JTAG+ISP  AVR programmer.

ADC error and Switch debouncing

Now that I have the IO hardware working, I have noticed a couple of issues in the potentiometers and switches inputs to the AVR:

1. Potentiometers readings in the ADCs are not stable and seem to fluctuate
2. Switch readings are bouncing on button press.

I found this great site: Newbie Hack where both topics are covered and clearly described. For the ADC stability issue, you can find this way of measuring the error. No info is giving on how to remove this problem, but I suppose a low pass filter should do. As for a way to do switch debouncing, you have it here. 

Still need to implement this solutions and try.

Update (12/03/2013):
Fixed the switch debouncing by only reporting switch changes after a certain number of unchanged reads, similarly as explained in the links above.
For the Potentiometers, I added some histeresys, I only report potentiometer changes when the read value exceeds the previously sent value by a certain amount, which gets rid of all bouncing issues, althought the cost is high as the potentiometer changes are not as smooth as they could be. still need to work on that.

JUNO6PM Enclosure

Been working lately on casing all the hardware. This is how the box is looking now:

And these are the internals:

Still need to add a power off switch, audio input jack (I plan to use the same hardware for guitar processing), external USB and Ethernet connector, but at least I have all the synth part hardware ready.

Powering my RasPi

Just as many others, I got a small TFT monitor used in car reverse cameras. This monitor has a 12V DC input for power but, as SK Pang points out here, internally it has a 5V regulator and uses that for powering the unit. Unlike what SK Pang did, I did not need to replace the 12V power feed with a 5V one, what I did instead was get the 5V required for the Raspberry Pi from the monitor Regulator. 

My monitor is slightly different model from the one SK Pang has (although it looks identical externally).

The picture bellow shows how I connected a USB cable for feeding the RasPi:

And this is my RasPi powered by the monitor and showing a quick mock up of how the GUI will look. I used Mindchunk's OpenVG library to make that GUI (for now it is just a quick and dirty test).

Using Raspi Serial Port

Lately I have managed to find some time to dedicate to this project. I am currently working on the Hardware side, will have some pictures of the box I am making soon. I am also starting to do some GUI work using openVG. And just today I connected my AVR board to my Raspi via serial (was using PC before). I will be explaining the details of this last effort in this post.

So I am using the Raspberry Pi serial port to communicate with my AVR board handling all the control I/Os. I will explain here what I did for getting that to work:

The first step was to disable the console output via serial port. To do so, you need to edit the file /etc/inittab and comment out the following line:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

And editing /boot/cmdline.txt removing the references to ttyAMA0. This:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Should look like this:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait 

This info is all coming from here.

Once that is done, since I am working at MIDI speeds, you need the change the the UART clock speed. I added this inside config.txt:

init_uart_clock=2441406
init_uart_baud=38400

And I modified the /boot/cmdline.txt again adding "bcm2708.uart_clock=3000000":

dwc_otg.lpm_enable=0 bcm2708.uart_clock=3000000 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait 

Then setting up your UART as 38400 magically makes it be 31250 and MIDI. This is coming from here, here and here.

Did I say SW UART?? No... no... HW UART

After investigating the possibility of using SW UART for MIDI out, I decided to give up... I had lots of issues getting reliable serial baudrate conversion and did not have enough spare time to investigate further, as can be seen based on my lack of posts in the last few months. So I am now using HW UART, 31250 in, 31250 out... no conversions... and that seems to be working fine. Took me some time to actually get it right, I thought I was also loosing bits there, until I found out about the running status in Midi... dammed it.. should have read the midi specs!!!

On the Raspi side, I plan to do as explained here to get the serial port to work at 31250.

SW UART

My plan is to have my AVR board handle midi Input and send that to the Raspberry PI (as well as the potentiometer and switches status) through 38400bps serial port of the Raspberry Pi. To do so, the AVR will be receiving MIDI through the HW UART and will be sending serial data by bit banging.
I tried using the SW UART implementation of AVR lib, but it seems to be failing every now and then (actually very often). I was expecting it to "just work" and let me work on other stuff, but it seems like I am going to have to spend some time debugging the code from AVR lib or looking for other alternatives... I am not big expert on AVR coding, so I expect a few nights of intensive work.
Meanwhile, I am almost done modifying rtMidi to allow Midi comming through serial port.

USBtinyISP

Yesterday I got my USBtinyISP from HobbyKing, but had no time to test it yet. I already wrote the code for the AVR so I can't wait to try that. I still need to work on the midi reception in the Raspi, to change rtMidi to use serial midi (at a non standard baud rate) instead of ALSA midi. One possibility is to use ttymidi (which converts serial to ALSA midi messages), but my plan is to extend rtMidi instead and not use ALSA midi at all.

While waiting

While I wait for my AVR programmer, I have been working on the VA synth. This is what I have added this weekend:

LFO: Added the delay to the LFO. So LFO is now complete.
HPF: I played around with different filters, and I did not see the point. Will probably install a Juno106 clone VST and play around to figure out what should I be expecting from the HPF, cause as far as I tested it did not add much (or, considering it is a filter, did not remove much).
LPF: I added a new filter and that sounds A LOT better. Will record a sample soon. Also LFO now controls the filter. Still missing keyboard tracking.
AntiAlias: Added a better antialias downsampling filter.
NOISE: Improved the CPU performance of the NOISE section. I was just calling rand() before and that does not seem to be the most optimal. I added a random number generation technique which only required a multiplication and an addition.

One thing I want to start looking into is adding a way to store/load presets. I think I will use an XML file for that, but still not sure.

Lesson learned

A couple of lessons learned from yesterday's video of juno6pm playing porcelain:

1. I need to be able to allow any possibility between 1 channel with 6 voices to 6 channels with 1 voice.
2. Need more drum samples!!! 

Raspberry Pi playing Porcelain (Moby)

Video Description:


This is my Juno.6pm virtual analog synth plus sample playback drum machine playing Porcelain out of a Midi file I downloaded from the internet. Ableton Live is only working as a Midi Out device.
The drum samples are not quite the correct ones, but shows what it is capable of doing.

Juno6pm Input Board: Bad News

My AVR programmer stopped working today. That means my progress on the input board will be delayed until I can get a new one. I did a quick search and I think I will go with the USBtinyISP programmer sold by hobby king. One of the reasons to choose the USBtinyISP is the buffered IOs. The lack of those buffers is probably what killed my programmer.
In the mean time I guess I will continue working on improving the synth part and maybe prepare a video of both synth and drum machine.

Juno6pm Input Board: The Software

While looking for examples of bit banging serial, I came across this AVR library called AVR lib. It is a great library for lazy people like myself, not only for serial bit banging, but for anything else you might want to do with the AVR peripherals: ADC, UART, I2C, timers... should be able to finish the code quickly with this cool library.

Juno6pm Input Board: The hardware

The Juno6pm input board is the board that will handle MIDI input (to solve the CPU hogging issue caused by Raspberry Pi USB MIDI), the knobs and the switches. It will be connected to the Raspberry Pi through serial. The board I am planning on using is the AVR synth that I bought a while ago from elby-designs:

Since this whole project is a virtual analog synth, I decided that I will not be using my AVR Synth anymore and I better give it a better use (also I have little time do design a new board, build the pcb, solder components, etcetera).
The idea is to keep the 8 potentiometers, replace the 16 switches with momentary pushbuttons and remove the dac completely.
As for the software that will run in the AVR, it will receive MIDI from standard 5 Pin MIDI connector using the hardware UART and send it to the Raspberry Pi, toghether with potentiomer and switches values, by bit banging serial.
Once I am done with the whole project I might think of making a new board just for this project, but till then this will be my juno6pm input board.

AVR programming: Open Source saves the day

It was a long time since I last program an AVR micro and last time I did it I was using this programmer:

That I got from microcontroller shop.

So I installed AVR studio 6.0 in my Windows PC (which took ages, BTW), wrote a blinking LED program, set up the programmer and to my surprise flashing the ATMEGA failed. Seems like AVR Studio does not support this particular flavour of programmer. So I went back to AVR Studio 4.XX (don't remember the XX, but the latest AVR studio 4 available in Atmel's website) with same results. After searching for alternatives, I found WinAVR, which I managed to get to work fairly easily (with the help of ladyada's avrdude tutorial). Since it was using AVRDUDE for flashing and that is available for Linux also (and the nice atmel IDE was not good for me anymore), I decided to forget about Windows completely and develop for AVR in Linux. Found this explanation on how to use codeblocks for AVR programming, which is great, cause all the project (the VA synth and the Monome stuff) I did using codeblocks already, so that means I have the whole thing using a single development environment.
So, big thanks to everyone who anonymously helped me get this to work and in general to the open source comunity.

Next Steps

Here is a list of what I will be working on next:

1. Implement my MIDI to serial conversion: I will be doing a MIDI to 38400kbps serial conversion using an AVR micro. The reasons for doing this are:
• USB MIDI is a CPU hog in the Raspberry Pi
• I am still not sure if the raspberry Pi supports MIDI baud rates or not.
• I want to add some controls to the Pi that will use the same micro and will be sent to the Pi through the same serial
2. Add the control of the knobs and switches (get the knobs and switches status and send it to the Pi).
3. Put everything into a nice case.
4. Add missing functionality to the VA synth (as explained here).
5. Add missing functionality to  the Monome application.

I am hoping to finish 1 and 2 within the next 2 weeks. We will see...

VA synth

Where am I and what is the plan regarding the VA synth?
As mentioned, my plan is to do a Juno106 workalike (a workalike, not a clone). In that respect, I have the following blocks developed and working:
LFO: I have extended it to support square and sawtooth and I am missing the delay.
DCO: pretty much working as in the Juno, with the addition of triangular wave. I am planning on adding wave table DCO also.
HPF: this is currently missing in my design, but will add it soon.
LPF: I have the 24db/Oct resonant filter. I am not very impressed with its sound, so I might try other filters. I am missing the LFO control of the filter also and the keyboard tracking. I am using "Moog VCF variation 2" from here.
ADSR: done and working.
DCA: done and working.
CHORUS: done and working, but I want to make it a stereo chorus (currently both speakers get the same signal).

Other than that, I am sampling at 88200Hz and still need to add a low pass filter before downsampling to remove possible aliasing. Hopefully the 2 missing filters, HPF and anti aliasing filter, will not take much CPU.
I also want to add an arpeggiator and a step sequencer going to DCO, LPF, DCA to add some "weirdness".

Monome + Raspberry Pi

Basic monome functionality for now...

Video Description:


Video Showing an Arduinome (arduino based monome) connected to a Raspberrry Pi which is running a sample playback software synth with Linn Drum samples.
There is no pd or Max running on the Pi, not even monomeserial or serialosc, it is just a C program that processes the raw serial stuff coming from the Monome and converts that into calls to the synth.

Diagram update

Here Goes the updated diagram with the USB audio DAC

USB Audio on Raspberry Pi

One thing that I forgot to mention in my diagram in previous post was that I was planning on using USB audio as a way to get the sound out of the Pi, as the on board analog audio is pretty bad. I might modify the diagram...

In order to set the USB audio device to be the default audio device I did as suggested here: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=20866 and modified the following line in /etc/modprobe.d/alsa-base.conf

#options snd-usb-audio index=-2
options snd_bcm2835=-2

After changing that and rebooting if you do "cat /proc/asound/modules" you get 

0 snd_usb_audio
1 snd_bcm2835

showing that the USB audio sound card is indeed the default. That was all I needed to get the USB audio sound card to work correctly.

Juno.6pm Diagram

Here is the schematic diagram of how the JUNO.6PM will be. The MIDI connection I am still not sure if it will be USB MIDI or I will need to route it also through my AVR board handling knobs and buttons, as it seems that USB MIDI screws up raspi's performance (as discovered here: http://raspberrypisynthesizer.blogspot.com/2012/10/the-problem-with-usb-midi.html )

The Concept

So, where does the name JUNO.6PM come from and what is it exactly its going to do? I guess you are wondering.
JUNO.6PM is a midi + monome controlled virtual analog synth + sample playback drum machine. The virtual analog synth is a juno 106 workalike, with 6 voices, 1 dco, 1 lfo, resonant 24db/Oct lpf, chorus effect... I do not pretend to do a juno clone, as I have never played one, but I did use its audio flow as a reference for my design, mostly because of its simplicity. As for the sample playback drum machine, I have tested with Linn drum samples, but there is no reason it could use other ones.
I am doing the development in a linux machine and every now and then porting to raspberry pi, the expected final platform.
So, going back to the name, the JUNO comes from the virtual analog synth it tries to work like, the 6 comes from the 6 voices polyphony of the VA, the P(i) is the platform and the M comes from the Monome working as the machine drum controller.
At some point I am panning on adding also a 3.5" TV, 8 knobs and 16 switches for configuration. Meanwhile everything will be midi controlled.
Since an image is worth more than a 1000 words, I will make a diagram soon showing the expected setup.

JUNO.6PM is born

What: JUNO.6PM is my implementation of a software synthesizer + drum machine.
When: development started a few months ago and now it is taking shape into something usable.
Where: in my livingroom.
How: using a Raspberry Pi, a midi keyboard and a monome controller.
Why: because this guy: http://raspberrypisynthesizer.blogspot.com inspired me (and because he is not planning on making his work open source).
Who: just me, myself and I.