Mozzi Arduino synth lib on Oskitone Scout

Mozzi is an audio synthesis library for Arduino that can do multi-oscillator synthesis with filters and modulation on even an Arduino Uno.

Oskitone Scout is an adorable tiny keyboard kit, based on an Arduino Uno and entirely open source.

I’ve been playing with Mozzi recently after first hearing about it many years ago. The Scout seems like a perfect platform for those experiments. I’ve been putting on these experiments in the MozziScout github repo.

Here’s some examples of using Mozzi on Scout, along with the small mod needed to make it work.

  • mozziscout – a straight-forward Mozzi version of the ‘scout‘ sketch that comes on Scout
  • mozziscout_monosynth1 – a fat mono synth, made of two detuned oscillators and a single resonant low-pass filter. Also features different startup modes to tune synth paramters. (see sketch for details)
  • mozziscout_drums_bass – a 4-voice drum sample kit (bd,sd,oh,ch) and a single oscillator synth in one!
  • mozziscout_chordorgan – a 5-oscillator synth with built-in chords! Sort of like Music Thing Modular’s Chord Organ.
  • mozziscout_poly – a poly synth, sort of. Scout’s keyboards doesn’t allow true playing of chords, but with a slow release envelope and the playing of arpeggios, you can make chords
  • mozziscout_wash – a five-oscillator stacked chord sound based on the Mozzi example Control_Oscil_Wash
  • mozziscout_thx – an eight-oscillator stacked sound where the oscillators start at a random pitch and slowly converge to a chord. Vagugely based on THX Deep Note

Demos

“mozziscout_monosynth1”

“mozziscout_poly”

“mozziscout_thx”

How to mod your Scout

One way two swap this is where the two legs of the ATmega328 chip are lifted, and jumper wires are soldered on and plugged into the socket, as in the photo below.

Using normal Scout code

After this mod, you can still use your Scout like normal, just make sure to swap pins 9 & 11 in the code.

const int SPEAKER_PIN = 9;  // was 11
byte rowPins[ROWS] = {7, 8, 11, 10};  // was {7, 8, 9, 10}

How to install Mozzi

Mozzi is not in the Arduino Library Manager, but installing it is pretty easy anyway. The installation process is the same way you hand-install any Arduino library.

  • Go to https://github.com/sensorium/Mozzi and click on the green “Code” button, then click “Download ZIP”.
  • You will get a “Mozzi-master.zip” file. Rename it to “Mozzi.zip”
  • In the Arduino IDE, go to “Sketch” -> “Include Library” -> “Install .ZIP library…”, then pick your “Mozzi.zip” file.
  • Once it completes, you will see Mozzi in the list of available libraries and the Mozzi examples in “File” -> “Examples” -> “Mozzi”. Many of the examples will work with Scout but not use the keyboard.

Using Mozzi

  • Mozzi is very particular about what is in loop(). Do not put anything else in there. Instead put it in the void updateControl() function. See the sketches for examples.
  • Mozzi output is quieter than standard Scout (which outputs full-width square waves). Use an external amp for best results.


Two-Wire NeoPixel WS2812 LEDs

Neopixel LEDs with only two wires?! Just data & ground? What kind of magic is this?

This is my take on this hack that Parallax Propeller forum user “Tubular” posted about in 2014 (!)

The trick is that the data line is carrying power, and a capacitor and Schottky diode are on the strip to separate out the data from the power. The capacitor holds the charge (mostly) for the LEDs as the WS2812 data line goes LOW and the diode keeps the capacitor’s voltage from interfering with the data line.

To keep the strip powered, make sure to set the data line HIGH after every frame of data sent. This keeps the strip powered. This technique works with most any WS2812 / NeoPixel library on Arduino or CircuitPython. If you want to try two-wire NeoPixels out in Arduino, one way is to change your “strip.show()” (if using Adafruit_NeoPixel library) to the function “strip_show()” shown below. The example a lightly-edited version of Adafruit_NeoPixel’s “strandtest_wheel”.

For CircuitPython, check out this gist.

QTPy-knob: Simple USB knob w/ CircuitPython

I like minimal solutions to problems. I was playing with a CircuitPython-enabled QT Py on a breadboard with and a rotary encoder and I ended up making a USB knob, like many others have done before. But I realized: waitaminute, I can literally just plug the encoder directly onto the QT Py…

Thus was born the QTPy-knob. It’s one of the simplest USB knobs I’ve come across and it’s because the happenstance that a rotary encoder can usefully be plugged directly into a QT Py board and that CircuitPython is so powerful now it’s just a few lines to go from rotary encoder pulses to sending arbitrary USB keyboard or mouse commands.

I really liked the Griffin PowerMate from over a decade ago, so I decided to design a 3d-printable enclosure that echos the design of the PowerMate, but that works with the restrictions of the QTPy+encoder stackup and a Neopixel ring. The result is pretty good I think.

All design files are in the qtpy-knob github repo.

The code is must easier now than the media-dial project I started cribbing from. This is due to the fact that CircuitPython now has native support for rotary encoders and this knob is trying to do much less than media-dial project.

The electrical wiring is virtually non-existent, only needing three wires if you elect to add a Neopixel ring.

The assembly is described in the video above a bit, but you can also see what’s up in this CAD animation (thanks to the Adafruit_CAD_Parts repo for making the enclosure design easier)

The result with opaque plastic and clear LED diffuser ends up looking pretty cool.

Get HID Report Descriptors with “win-hid-dump” & “mac-hid-dump”

I help support the USB HID projects hidapi and node-hid. One of the aspects of HID that isn’t clear is that HID devices transmit and receive data with “reports”, fixed-size data packets. What reports a device responds to is described by the HID Report Descriptor it hands to the OS. The OS then only permits those reports to be sent and received. This descriptor is different from the USB Config & Device Descriptors Those two are easily discoverable using standard system tools, but for whatever reason, getting HID Report Descriptors is much harder.

To address this, I’ve created two tools: win-hid-dump and mac-hid-dump from code snippets around the Net. They are akin to simplified versions of usbhid-dump for Linux. They print the HID Report Descriptors of the HID devices currently connected and the output can be parsed by things like https://eleccelerator.com/usbdescreqparser/

The tool repos with pre-compiled releases:

I’ve found many of the issues I have in supporting node-hid is getting people to understand that you need to know the type and sizes of the reports you want. Hopefully they’ll be useful to others as well. Let me know if you have any issues with them.

The output looks something like:

tod@demo ~/Downloads/mac-hid-dump$ ./mac-hid-dump
mac-hid-dump:
16C0 0486:  - Teensyduino RawHID Device
DESCRIPTOR:
  06  c9  ff  09  04  a1  5c  75  08  15  00  26  ff  00  95  40
  09  75  81  02  95  20  09  76  91  02  95  04  09  76  b1  02
  c0
  (33 bytes)
16C0 0486:  - Teensyduino RawHID Device
DESCRIPTOR:
  06  ab  ff  0a  00  02  a1  01  75  08  15  00  26  ff  00  95
  40  09  01  81  02  95  40  09  02  91  02  c0
  (28 bytes)
27B8 01ED: ThingM - blink(1) mk3
DESCRIPTOR:
  06  ab  ff  0a  00  20  a1  01  15  00  26  ff  00  75  08  85
  01  95  08  09  00  b2  02  01  75  08  85  02  95  3c  09  00
  b2  02  01  c0
  (36 bytes)
tod@demo ~/Downloads/mac-hid-dump$

DIY Neopixel / WS2812 Development Kit

If you are like me, you play around with Neopixel / WS2812-style LEDs a lot. Normally I solder my own custom-connectors and don’t use the ones that come with the reels I buy. But since we’ve been playing around with WS2812-compatible Xmas lights, I decided to make a “Neopixel Dev Kit” for easier experimenting with different LEDs and different ways of powering them. Most LED reels come with a 3-pin JST SM socket (female) connector installed with also maybe a 2.1mm DC barrel connector to inject power (see reel picture below). They’ll also throw in a pigtail JST SM plug (male) connector to attach to your controller. So I standardized on this. The kit as shown consists of (from bottom to top):

  • 3-pin JST SM socket (female) added to weird new WS2812-compatible Xmas lights
  • Known-good USB-powered WS2812 controller from those lights, rewired with JST SM plug
  • Standard 3-pin JST SM plug to JST SM socket, with 2.1mm DC barrel connector power injector
  • 3-pin JST SM plug (male) to header pins, for breadboarding
  • Known-good normal WS2812 strip with JST SM socket
  • 5V power supply with 2.1mm DC barrel connector
  • USB power meter for seeing voltage & amps drawn by any particular setup (see example below)
  • Arduino Pro Micro clone on tiny breadboard. This is a 5V microcontroller, so no need to worry about 3.3V -> 5V data issues. And it’s cheap in case we blow it up

Overall it’s working out okay. I need to add a few “sacrificial neopixels” to the mix to make using 3.3V-based microcontrollers and maybe some breadboard screw-terminals.

WS2812-compatible “fairy light” LEDs that know their address

I’ve not done much on our plotter Xmas tree this week because, well… if you follow me on Twitter, it’s likely you’ve seen me ramble on about these crazy new Christmas Tree lights we got for our tree (first tree ever!). I wasn’t able to find appropriate “Christmas Tree” light forms of the WS2812 lights, but Carlyn did! And they were even better than normal Xmas light styles. These were “fairy lights” with small beads of light connected by solid enamel-coated wire that almost disappear visually. The LED string appeared to maybe be WS2812 / Neopixel compatible and yup, they were! But the weird thing was, as I learned was discovered back in November, these LEDs remember their address when cut out of the strand. If you’re familiar with WS2812-style LEDs, this is bonkers. Normally these LEDs have four pins: +5V, Gnd, DataIn, and DataOut. To make an LED strip, the LEDs are wired in a chain, one LED’s DataOut going to next LED’s DataIn. This is great! It means you just have one wire to control hundreds of LEDs!

What’s going on with these LEDs? You cut them up, wire them in parallel (there’s no data “in” and “out”, just “data”) and they still know where they should be in the data stream, only picking the data for them. I’m still researching this with the help of some friends who can navigate Shenzhen better than me, but it’s looking like these LEDs have their address set OTP (one-time programmable) at the factory. No LED part number yet. If you’d like to get some to try yourself, here’s the 100-LED exact Amazon ASIN I bought as well as the 200-LED ASIN Carlyn originally found (both affil links).

Here’s some pics showing the box and how I took it apart to test on an Arduino Micro clone.

Precise flood fill with AxiDraw

We recently got some inexpensive multicolored 0.3mm technical markers (AmzAffil) for use on the AxiDraw and they are pretty good! For this week’s batch of days for our 31-box AxiDraw calendar, I wanted to play with doing “flood fill” / solid color fills. Normally the “hatch fill” extension part of the AxiDraw Inkscape extensions creates slanted lines to imply a filled color. I knew a true full fill would be touchy because the paper can tear when fully inked, but I wanted to try. It turns out to work great!

There’s not much of a trick to it, just adjust the “hatch fill” algorithm to have closely-spaced lines (“2” for a 0.3mm pen worked well) and “connect nearby ends” to go back-n-forth to minimize pen up/down messiness. Also orienting your hatch direction, optimizing for your object (0º in my case) can make the fill succeed better. Plotting does take a while (especially for multi-colors like the 12 ornaments) and does cause some bleed-through. But I think it looks awesome.

And the video of it is mesmerizing: