One of the benefits of having a easily-generated CAD model of a PCB with components, it becomes possible to test possible interference and clearance of connectors and cables. In this case I was worried the Eurorack power cable (2×5 IDC connector) might interfere with the micro-USB plugged into the ItsyBitsy M4. So far looks good. So I sent the board to fab and should have some to play with next week.
“knobtester” for Touring Machine module
When designing my new Touring Machine synth module, two things worry me: the analog I/O section (it must be pitch-accurate) and the user interface. The UI feels like a harder problem because I’m not sure what I want. For the analog part, I can lean on others (like Émilie and Thea) and that puts me at ease.
So to address the UI as its own thing, I made a little “knobtester” PCB that is the scale and layout of the upper third of the module. It contains all the things you put your fingers on: a rotary encoder w/ switch, two buttons, and two potentiometers. Just from the outset there are questions: Should the encoder have detents? What’s the spacing of the two pots so your fingers can grasp them? Should the pots have knobs or be trimmers? How tall do the tact switches need to be? Making the board physical answered some of these questions immediately (“yes”, “as much as possible”, “trimmers, maybe with micro knobs“, and “13mm”)
Here’s the board fresh off the Othermill.
The Start of the Touring Machine Eurorack module
The original goal of my month-long Deep Fried Neurons project was “30 sounds, one per day”, an exploration into making sounds with Eurorack gear that doesn’t use sequencers or keyboards. While I only created 15 sounds so far (I’ll still do all 30 I think), I’ve been increasingly using some home-built modules like my TrinketTrigger and TrinketTouringMachine, and that’s given me ideas.
So for my next month project, I’m going to design and build a production-ready module that expands on what I’ve learned. It will be a better “Touring Machine” algorithmic melody generator that builds on the TrinketTouringMachine, but offers proper modular synth signal in/out and additional control knobs. It’s also a platform for getting over my reluctance to designing opamp circuits, something I was okay at once many years ago. I’ve got the start of a design based on an ItsyBitsy M4 and will be prototyping next week.
Trinket Touring Machine
I’ve been playing more with algorithmic melody generation by working on my own module I’ve been calling the “Trinket Touring Machine“. Like my previously-mentioned “Trinket Trigger“, this one uses a Trinket M0 running CircuitPython. Initial experiments were in Arduino using the Mozzi audio synthesis library, which totally worked, but CircuitPython is much faster to develop in, especially when you’re trying to discover what the UI should be.
My original intent for this Touring Machine module was to make a CircuitPython-based version of Music Thing Modular’s wonderful “Turing Machine”, which is essentially a clever shift-register circuit hooked up to a DAC (no microcontroller!), with an adjustable noise generator for randomness. But my module has gone a bit more melodic, having the concept of scales and root notes. It’s pretty fun, but I know now the two knobs and one button UI is too limiting for what I’m envisioning. So time for Touring Machine Mk2!
30 sounds, one per day
I’ve decided to do “30 sounds, one per day”. I’m a bit behind, but here’s a Youtube playlist of what I have so far and the corresponding Bandcamp album. These are to be sounds. Not tracks, not songs. Just interesting sonic experiments. I want to make sounds I’ve never heard before, or sounds I’ve always wanted to create. For tools, I’m making myself use only hardware music gear, no Ableton Live, no VSTs. And minimize the use of MIDI sequencers. (The tracks thus far are made rhythmic purely from envelope generators) Some homemade gear might make an appearance and that could fun too.
JAMuary 2020: Modular synths & Deluge
I’ve been getting back into music lately, thanks to the wonderful Synthstrom Deluge. And thanks to John Park, I’ve been getting into Eurorack modular synthesizers. It’s really fun, but can get pricey fast. I would recommend everyone download the free VCV Rack so you too can patch together sound modules like audio Lego and make weird noises.
Part-way through January I learned of the “#JAMuary” tag on Instagram and I felt I had gotten proficient enough with both the Deluge and the modular gear to make a few tracks.
Here they are. It’s both incredibly freeing and incredibly frustrating to finish a track and then pull out all the cables, erasing the piece, never getting it back exactly like before.
If you like any of these, they’re available for download from https://todbot.bandcamp.com/
hidapitester – Command-line program to exercise HIDAPI
To help diagnose USB HID communication and to test out updates to hidapi, I wrote hidapitester. It is a command-line program that allows you to exercise just about every aspect of hidapi. Pre-built binaries for MacOS, Windows, and Linux Ubuntu x64.
I’ve found it very useful. You can use it to:
- Scan for connected HID devices, optionally by VID, PID, usagePage, usage
- Send OUTPUT reports, with or without Report IDs
- Receive INPUT reports, with or without Report IDs
- Send FEATURE reports, with or without Report IDs
- Receive FEATURE reports, with or without Report IDs
Commands are specified in-order on the command-line, so you can do all of these, repeated reads, close-and-open, etc. all in a single command. More details can be found on the hidapitester github README page.
It is written in really vanilla C to maximize compatibility and ease-of-compilation.
Here’s the help page:
Usage:
hidapitester <cmd> [options]
where <cmd> is one of:
--vidpid <vid/pid> Filter by vendorId/productId (comma/slash delim)
--usagePage <number> Filter by usagePage
--usage <number> Filter by usage
--list List HID devices (by filters)
--list-detail List HID devices w/ details (by filters)
--open Open device with previously selected filters
--open-path <pathstr> Open device by path (as in --list-detail)
--close Close currently open device
--send-feature <datalist> Send Feature report (1st byte reportId, if used)
--read-feature <reportId> Read Feature report (w/ reportId, 0 if unused)
--send-output <datalist> Send Ouput report to device
--read-input [reportId] Read Input report (w/ opt. reportId, if unused)
--read-input-forever [rId] Read Input reports in a loop forever
--length <len>, -l <len> Set buffer length in bytes of report to send/read
--timeout <msecs> Timeout in millisecs to wait for input reads
--base <base>, -b <base> Set decimal or hex buffer print mode
--quiet, -q Print out nothing except when reading data
--verbose, -v