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.
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!
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.
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.
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:
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
I upgraded the firmware on my beloved-but-long-unused 1986 Oberheim Matrix 6r! These synths are the royalty of analog fatness. I love their sound. This is the result I was looking for:
It’s remarkably clean inside for a machine made in 1986. I acquired it used in the early 90s.
Just look at the bank of six voices. The CEM3396 chips are the VCF/VCA chips that give this synth its distinctive lushness. And made each voice circuit like 5x smaller than possible just a few years earlier.
The firmware upgrade was just a simple EPROM swap. Out with the old, in with the new! I got the chip from a chap on Reverb who’s using new EPROM stock (not old ceramic parts) The firmware update itself allows the Matrix to be used with modern MIDI patch editors and is a testament of amazing microcontroller assembly language hacking. Check out the page by the author of the Matrix firmware update. Thank you so much!
And the result is the same as before the upgrade: it still sounds glorious.