• Early keyboard prototype

    Matt Bradshaw01/15/2019 at 18:16 0 comments

    The other day I stumbled across this project for a modular keyboard design (modular in the general sense, not as in modular synthesis): https://hackaday.io/project/6737-modular-synthesizer-controller-keyboard-case

    It inspired me to keep thinking about a physical keyboard for PolyMod 2. I've recently gotten the hang of 3D printing a bit better, so I decided to prototype a keyboard design in PLA. It's based on the plastic toy keyboard keys that I used in PolyMod 1, but scaled up to be the size of MicroKorg keys (about 8cm long). The springiness comes from a thin strip of plastic between the key and the anchor point.

    Each key pushes down on two silicone buttons, the idea being that you'll hit one button first, then the other a few microseconds later, and the time taken will yield a "velocity" value. So far I haven't managed to get this to work reliably, but already this design works fine as a non-velocity-sensitive keyboard, so I'm hopeful! Here are some pictures - I'll release some STL files once I've developed the design a bit more.

  • Memory Problems

    Matt Bradshaw01/03/2019 at 13:54 0 comments

    A little summary of progress over the past week or so:

    I've briefly diverted my attention to developing a stripped-down version of PolyMod, because I'm writing a magazine tutorial on how to build a digital synth. This version fits on two breadboards, has 16 patchable sockets, a few knobs, a couple of LEDs, a miniature keyboard and a MIDI input. This has been a useful experience, because I've gone right back to basics with the design and code.

    The stripped-down version uses a Teensy 3.2, which has forced me to think about memory usage. With the Teensy 3.6, I was able to be quite cavalier with the amount of memory I used. I tried more and more complex patches, and the 3.6 never struggled. However, with the 3.2 I soon started running into problems. After a bit of experimentation, I realised that there was a memory leak in the Teensy audio library when disconnecting a virtual patch cable. This is now in the process of being fixed in the core code - more details on this forum thread: https://forum.pjrc.com/threads/54760-Audio-stops-working-when-repeatedly-creating-disconnecting-AudioConnections

    A helpful user on the forum also pointed out that dynamically creating unlimited audio connections is a recipe for disaster on the Teensy. As an alternative, he suggested a series of mixers to connect the different modules. I don't know whether I've understood his suggestion correctly, but I tried implementing a version of this approach with the stripped-down breadboard PolyMod, and it worked really nicely. Basically, everything is permanently connected to everything else - a mixer is placed before every module input, and every possible module output is routed into each mixer, with the patching being controlled by adjusting the volume of each mixer channel. This creates a huge number of audio connections but, crucially, the connections are known at compile time, meaning that the issue of dynamically creating too many patch cables is solved.

    This approach is probably not feasible for a full PolyMod design, partly because the module types are not known at compile time, and partly because it doesn't scale very well as the number of sockets increases (my maths-lecturer friend seemed to think it scaled quadratically, although we were in the pub at the time). However, it's an interesting alternative approach.

    Anyway, I'll post the magazine article here when it's published, probably in February - might be an interesting (and less daunting) way into the PolyMod project than building a big eight-module synth.

    Oh, and the MIDI input works really well - I borrowed the code and circuit from the official Teensy site: https://www.pjrc.com/teensy/td_libs_MIDI.html

  • First Steps

    Matt Bradshaw12/24/2018 at 15:45 6 comments

    I'm sitting by the fire with my very old cat, writing some preliminary code for PolyMod 2. It's going pretty well thus far - starting from scratch but being able to refer to the old code is very freeing. Here's a summary of what I've been up to:

    Case design: I'm trying to emphasise a no-fuss approach to the case design, keeping everything as simple, sturdy, and uncontroversial as possible. With this in mind, I think I'm going to base the main body around a pre-made aluminium box. This one (Hammond 1444-32) looks like a good candidate, and is only about £25. This box would be used upside down. Most of the top surface will be filled with modules (see below), and the rest will be either 3D printed (for the prototype) or possibly cut from aluminium for the final thing. A plywood box would work fine, too. To clarify, this design will be roughly the size and shape of a MicroKorg, rather than the retro angled Minimoog shape of the first PolyMod.

    Module physical design: the first PolyMod used modules with circuit boards mounted (precariously) at right-angles to the face-plate. Since I'm going to be using PCBs rather than stripboard this time, I can make better use of the space and mount the circuit boards flat behind the face-plates. The current plan is to base the module size on a 12HP Eurorack module. Obviously the digital PolyMod system is incompatible with the analog Eurorack system, but I can't think of a good reason to diverge from the Eurorack sizing standard right now. The face-plates will probably be 3D printed for the prototype and maybe cut from aluminium for the real thing. I'm toying with the idea of a push-fit (friction) module system, rather than the thumb screws I used before. I'm also considering the idea of removable card labels for the module face-plates, since the modules will no longer have a fixed "identity" (a module with three knobs, six sockets and an LED will happily be able to function as either an LFO or a VCO, for instance). Whether I can make this idea aesthetically pleasing is an open question.

    Module features: the previous PolyMod's modules could handle eight sockets and eight knobs. The new ones should be able to handle eight sockets, eight knobs, loads of LEDs (via a shift register), and either loads of switches/buttons (via a shift register) or an extra eight knobs. Pretty pleased with this upgrade, although it's currently totally untested.

    Menu system: I've started coding a menu system to allow you to save and load patches, with the option of restoring the patch cables. This could get pretty complicated when combined with the modules-can-change-their-identity feature. The display will almost certainly be a standard 16-character, 2-line LCD, because they're cheap and easy to code for. Might have to upgrade to a 4-line display depending on how the UI works out - they're only a couple of quid more.

    Module library: one of the more exciting new elements of PolyMod 2 is the public module library, which I've begun coding. The UI is nothing fancy, but so far it's coming along fairly well. It will be optional, though - I'll make sure the default Arduino/Teensy code contains a good basic selection of modules.

    Physical keyboard: I'm 99% certain there will be a MIDI input on the synth, but I'm also toying with the idea of a basic physical keyboard. I had given up on doing this again, after the unimpressive clicky keyboard of the first PolyMod, but I've recently discovered a component that I wasn't aware of before (basically a silent version of a tactile button) which may make it relatively easy (famous last words) to implement a simplified keyboard. And if I could somehow make it microtonal with a menu setting... no, keep it simple. Too many possibilities!

    More module slots: this feature is on hold for the moment. I may be able to have eight proper slots rather than seven (i.e. the master module won't count), but I don't want to bite off more than I can chew with the next prototype. I'm hoping that I'll find...

    Read more »