Marc Nostromo

A view askew on music technology

Screen Shot 2014-09-30 at 08.34.21

September 30, 2014
by nostromo
0 comments

Doué Pt.2: waveforms

Every Monotron offers slightly different pad points on the pcb to allow us to to fiddle with. The duo is no exception and is actually fairly comprehensive:

monotron_pcb

It seems one of the focus here is to give access to the various waveforms the oscillator cores go through internally. We can also find these point on the duo’s schematics:

Screen Shot 2014-09-30 at 08.34.21

First of all, we see the default output of the oscillator is a square wave (SQR1) – to the contrary of the regular monotron which outputs a saw. There is a SAW1 point where we probably can tap an equivalent saw to the original and a PLS1 with some kind of pulse train. Interestingly, the pulse train is labeled “VCO1″ which feeds the TI chip. This means probably the pulse train’s existence is not for any “musical” purpose but for frequency measurement. To be sure of what we’re dealing with, let’s quickly power the monotron, grab a scope and have a look:

  • SAW1

Capture d'écran 2014-09-30 07.37.01

  • PLS1

Capture d'écran 2014-09-30 07.35.47

  • SQR1

Capture d'écran 2014-09-30 07.36.43While PLS1 and SQR1 go nearly rail to rail (0->5v), SAW1 is way quieter (although still roughly centered around VBIAS). We can easily bring SAW1 to the level of SQR1 by amplifying it by a factor 5 and, possibly, make a SAW/SQR mixer like mutable instrument’s Anushri does.

PLS1 looks as expected and it will be interested to see how one could connect it to a teensy pin to measure it’s frequency, providing a feedback for proper self-tuning of the voltage sent.

We’ll look at that next time.

 

 

Screen Shot 2014-09-27 at 20.21.42

September 28, 2014
by nostromo
2 Comments

Doué Pt.1: controlling the monotron duo’s Pitch

Pitch access

Controlling the monotron duo’s pitch is a little more tricky than the regular monotron. For one, it doesn’t have a pad on it’s pcb for pitch control. Then, the monotron duo has a small Texas Instrument chip that allow it to play the ribbon in note steps rather than the continuous sweep.

Screen Shot 2014-09-27 at 20.21.42

Although it’s an interesting feature – it seems also somehow the chip receives some feedback from the vco1 itself, possibly to do automatic pitch calibration – it also comes in the way of external pitch control. The only pitch control point provided is Vrib on pin2, meaning it doesn’t bypass the chip’s processing. This means first that the pitch is quantized but, more importantly, that the control rate is limited to the ribbon’s 14 semi-tones, which is a bit disappointing compared the 4 octave range the original monotron can provide.

So we need to find an alternate way to control pitch. One could be finding the equivalent point of the Pitch trace on the original monotron but Alessandro Fasan took an interesting path: remove the pitch potentiometer and drive the pitch from it’s central pin. Rather than controlling the pitch offset using the potentiometer, we”ll simply apply voltage generated by the dac to simulate the effect. This has also a rather good side effect: on my first nostromotron, getting the pitch of the analog oscillator tuned is always a tad fiddly due to how sensitive the pitch potentiometer is.  By ‘removing’ this feature and placing the mcu control at that level, we gain a much better control over the oscillator’s pitch.

Removing the potentiometer is a bit fiddly and requires some patience, but you can also go the short way by “hacking” the potentiometer’s leg off the pcb and solder a wire to the middle point. Not pretty but hey, it works:

2014-09-27 21.01.18

So, using a schematic similar to the original nostromotron mod, we can now hook a MCP4822 dac to a teensy and send some voltage to control the pitch.

However, things get a little complicated from here…

Mapping voltage ranges

Trouble is, the usable voltage range to control the pitch this way is fairly different from what the dac can deliver.  Doing a 0->5v sweep on our newly uncovered pitch shows that control is only effective above 1.4v. Our dac though can only provide voltages between 0->4v. So if we do a direct connection between the dac and the pitch control, we’ll lose 1.4v on the bottom end of the dac (nearly a third of it’s range) and will never be able to reach the 4->5v range.

So we need somehow to ‘map’ the 0->4v range of the dac to the 1.4->5v of the pitch control. This is a good job for an op-amp but for some reason, I always find these configuration to be more complicated than they should. Let’s dive into some simple math:

Let’s consider at an op-amp in a typical active inverting amplifying configuration.

opamp

Our opamp is wired in single supply mode with Vcc being 5v and VBias being 2.5v.

We know that vout will correspond to Vin – mirrored across VBias – and ‘amplified’ by a factor R3/R1

Vout = VBias + (VBias – Vin) * R3/R1

Therefore, we can deduce that going from the dac’s 4v range to the pitch’s 3.6v range will lead to

R3/R1  = 3.6/4

Using this value, we can compute the resulting voltage from our straight amplifying configuration applying the dac’s voltage range to the input:

Vin = 0v -> Vout = 2.5v + (2.5v – 0v) * 3.6/4 = 4.75v

Vin = 4v -> Vout = 2.5v + (2.5v – 4v) * 3.6/4 = 1.15v

So we see that, in order to match the desired range, we still need to offset/raise the signal of 0.25v.

We do that by creating an additional constant current through R3 using a another resistor (R2) connected to the ground. Here’s the full schematics:

opamp copy

Since the opamp is in an inverting configuration, the contribution of R2, wired to the ground, will be to shift the output up, which is what we want. The amount of offset is determined by

offset = (Vbias -0v) / R2 * R3 = 2.5 / R2 * R3.

Since we want an offset of 0.25v, we get

R3/R2 = 0.25 / 2.5

Knowing the ratio of R3/R1 and R3/R2 now allows us to select a value of R1 and deduce the 2 others. For example, if R1 is 1K, we get R2 = 7.26k and R3 = 0.88k.

However, here comes the extra difficulty: resistors don’t have any given value.  Depending (mostly) on the resistor’s tolerance, there’s a fix number of resistor values per decade. For example my set is an E12 (12 values per decade) . This means that you can’t just compute resistor values but need to find which combination of E12 values gives you values that are the closest possible to what you want. I’ve spend a good deal of time yesterday trying to find some “clever” algorithm to find it but in the end, I used brute force : evaluate all the combination, calculating their output range, filter the obvious miss and going through the results manually.

I ended with the following configuration:

R1 = 3,9K | R2 = 22K | R3 = 3,3K

For a predicted output range of  1.52->4.99v (this will vary due to resistor tolerance). I’m getting the following:

OLYMPUS DIGITAL CAMERAOLYMPUS DIGITAL CAMERA

 

Which is close enough for comfort.

Wiring the monotron

An important note is that since we want to produce voltages that are close to Vcc, it is important to select an opamp that allows rail to rail operation (i.e. it can output very close to the positive and negative supplies without clipping the output). The TI TL07x aren’t for example, they will clip at about 2v from VBias. So instead we’ll use a TLV2472.

We’ll also feed temporarily Vrib to 5v in order to get the highest frequency range possible. We might end up later playing with this voltage too, in conjunction to the pitch control to either increase the resolution of the output but we’ll see that when doing the pitch calibration.

Finally, we’ll hard wire the gate pad to 5v too so the monotron produces sound continuously. Since we plan on hooking up a VCA at the end of the chain, we don’t need to ‘trigger’ the osc/filter.

The current setup gives us an osc1 frequency ranging from 50hz to 1Khz, which is a little more than 4 octaves. The second oscillator is still tunable manually way above that, so it all feels good !

Next time will be calibrating, and we’ll try some interesting auto-calibration technique.

September 25, 2014
by nostromo
0 comments

Nostromotron Doué

I’m going to start working on a new version of the Nostromotron. Although I still really love the original one, I feel like I’ve learned a few things since then and I’d like to apply them to a new version of the mod.

So be prepared for a few posts about doing this new version I now call ‘doué’.

Here’s a few highlight of what I’d like to do for this one

  • Base it on the monotron duo, basing the design on Alessandro’s - itself based on my original one.
  • Better pitch accuracy: Get rid of the tuning ‘problem’ – some might call that a feature – due to the sensitivity of the pitch knob
  • Use DDS for the digital oscillator to get a less aliasing
  • Add a VCA post-filter (this will also get rid of the gate clicks since the gate can always be open)
  • Make use of the tap points on the pcb for various waveshapes
  • Use bypass capacitors on chips – as I am supposed to.
  • Do a proper casing so I can fully tweak it without any additional help.
  • “Real” MIDI port (but still support usb over midi)

So, all in all, this should end up being a cleaner version of the unit. Let’s see how it rolls.

August 14, 2014
by nostromo
0 comments

Re-tuned

I’ve noticed my nostromotron was slightly off due to rounding error in the code. I’ve also taken the opportunity to check the analog oscillator scaling over the note range. The end result sounds way less toyish and it feels smoother now.

You can grab the last version of the code over at github.

OLYMPUS DIGITAL CAMERA

May 29, 2014
by nostromo
0 comments

MFB-522 Sample pack

I had Ian’s MFB-522 for an afternoon. It’s a fantastic little drum machine so I decide to make a sample pack with it. It won’t replace the fun to tweak the real thing but might come handy.

Download here: MFB-522

OLYMPUS DIGITAL CAMERA

OLYMPUS DIGITAL CAMERA

May 25, 2014
by nostromo
16 Comments

Using ODroid U3 and arch-linux for Audio applications

OLYMPUS DIGITAL CAMERA

The ODroid U3 surely rocks the house. With 3 usb port it can fit any combination of external control you would like [Launchpad, nanoKontrol, Audio out, ...] , a processing power that blows the Rpi to dust,  it shines it the best standalone cpu platform I’ve come across so far.

Installation-wise, I installed arch-linux and compiled my synthesis framework in about 3h without a glitch (except for the built-in audio not being recognised by ALSA), and it auto-boot to any app in about 13 seconds.

I enjoy now close to unlimited number of Braider voices while the Rpi puked on three.

So, no matter whether you want to write synthesis software or use any of the Linux classics like pd, super collider, etc.. I’d hugely recommend it.

 

logo

January 13, 2014
by nostromo
0 comments

Telsonic Segment Jam

IMG_0009

Now that I’ve tamed the feedback part on TelsonicSegment, it’s a lot easier to explore its sound space without getting [too] all over the place. Here’s a quick jam done this morning using a simple setup with my RaspPie running Telsonic Segment fed through a DOD 250 clone into a cheap Behringer mixer clone.

Loads of flavors !

distributor-logo-archlinux-1

January 6, 2014
by nostromo
1 Comment

Installing ArchLinux on Raspberry Pi for headless audio

Since I’m re-doing a fresh install of a SD card on my Raspberry Pi, I thought I’d document the process as I go, in case it is useful for other people (or for my future reference in the most likely case we’re I’ll screw my current SD). I”ve chosen to use ArchLinux over Raspbian because it boots faster and has a smaller footprint. Since I’m mainly interested in using the Raspberry pi headless – without any screen or keyboard attached – it makes sense to have a reduced system to start with. On my current SD, it takes about 10 seconds to boot into the app of my choice, that’s way better than bringing any of my computer back from sleep and firing the equivalent app.

Important note 1: As always, this is heavily time dependent and I can’t guarantee the exactness of this post at any other future dates.

Important note 2: When you changes files on the Rpi and need to reboot, don’t plug the power out. You have a lot of chances files where not committed to the SD yet and all your edits will be lost

1 – Build a SD card

The steps are explained over here, in the installation tab. It’s the pretty standard “download the image and do a SD card dump” procedure. Under linux, use dd. With Windows, you will need Win32DiskImager. Once the image is done, remove it from you computer, stick it into the Rpi’s SD slot and boot it up. The image is setup to use DHCP, so if you you can simply power the Rpi connected to an ethernet cable and – provided you can find its ip –  you can directly ssh to it. Otherwise, you will need to connect it to a screen and keyboard and login that way. The default username/password of the image is ‘root’ / ‘root’. The default hostname is ‘alarmpi’.

2 – Setup the package manager

Since you will need to install some additional libraries / packages, it’s a good idea to setup archlinux’s package manager, cutely named ‘pacman’. You can find information about the process over here (look for update system). You can update the system too if you want, nothing wrong with getting the latest while we’re setting up.
The steps I’ve followed are:

  1. Create a pacman key:

    # pacman-key –init

  2. Update the system (this will take a while):

    # pacman -Syu

  3. Reboot

    # reboot –reboot

3 – Adding packages

Now you need to find and install packages that are missing. You can look for packages through keywords using

# pacman -Ss keyword

And install them using

# pacman -S keyword

In my case I ended needing was sdl, alsa and jack:

# pacman -S sdl
# pacman -S alsa-utils
# pacman -S jack

4 – Testing usb midi/audio

In theory, you don’t really need to execute this step (since everything should work smoothly) but I always like to double check things:

Connect a USB audio device then type

# aplay -l

You should see an entry both for the internal audio device (bcm2835) and USB audio.

card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 2: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

Then plug in a MIDI device and see if alsa recognises it:

#  aconnect -o

client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0′
client 20: ‘Launchpad’ [type=kernel]
0 ‘Launchpad MIDI 1′

5 – Removing the default pi audio output

Since the built-in audio out of the raspberry pi is only good for deaf people, it makes sense to remove it. Raspbian has a sysem that makes any usb audio the default one but arch linux doesn’t. Since we want it to work with anything we would plug into it, we’ll just get rid of the bcm2835 so it doesn’t get in our way. To do so, edit the file /etc/modules-load.d/raspberrypi.conf and remove / comment the bcm2835 related modules (bcm2708-rng, snd-bcm2835)

6 – Autobooting

If we want to use our raspberry pi as a headless sound device, it’d be nice to get it to start some programs automatically at boot time. So far, the easiest way I’ve found is to use crontab.

Crontab has a special syntax that allow some command to be executed at boot time. So we’ll create a shell script in our root folder and get cron to execute it everytime we restart the Rpi. If we want to change the start sequence later, we simply need to update the shell script.

Start by editing root’s crontab:

# crontab -e

And add the following line:

@reboot /root/autostart.sh > /root/autostart.log 2>&1

which tells to execute a shell script – autostart.sh – located in the root home and to log all output from it into autostart.log

Now go in the root folder (cd /root) and create autostart.sh containing, for example, the following:

echo “hello world”
exit 0

Make sure the autostart.sh is executable by

# chmod a+x autostart.sh

And reboot the rpi:

# reboot –reboot

When you reconnect to the Rpi, the root folder should now have a file autostart.log containing

hello world

Bingo ! Now we can start any favorite program to start at boot time !