Matt BradshawI'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 time to do a breadboard test with 16 modules, just so that I know the code won't have to be completely rewritten in the future. I also had a helpful suggestion from the Hackaday community that I could make the module scanning manual rather than automatic, i.e. there could be a "rescan connections" button. This might speed up the code considerably, particularly if we move beyond eight modules.
Okay, that's probably enough rambling for now. The code is on GitHub if anyone wants to watch its medium-slow progress. Oh, and the very rough projected cost of components for this project is £200 at the moment, but that could obviously change.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I have used port manipulation in an Arduino NANO-based shift-light I built for a kitcar. Much faster than digitalWrite, but more difficult to use. Have you seen this?: https://forum.pjrc.com/threads/39053-Portmanipulation-for-Teensy-3-6 .
I will have a go at knocking up a test rig and some code to demonstrate my rewiring idea. For my mux rewiring to work I would need to use analogue Teensy ports for the main data lines which may introduce other problems.
The idea behind the mux wiring reorganisation is to maximise the benefits from not having to continually monitor the module configuration lines. For the simpler modules, this would mean that you only needed to continually monitor the analogue lines connected to pots. With the existing module wiring, if you want to monitor 8 analogue lines then you need to switch the analogue mux 8 times to connect the single Teensy port to them. Under the new idea, if you wired the 8 analogue lines to, say, channels 1 and 2 on the 4 module chips, you would only need to switch the muxs twice to read the 8 analogue levels on the 4 Teensy ports.
Are you sure? yes | no
Cool, that makes sense - good luck, and let me know how you get on.
Are you sure? yes | no
Interesting stuff Matt. I plan to keep one eye on what you are up to whilst trying not to get sidetracked from what I have chosen to call my PolyMod 1.2 -- and probably failing!
Are you sure? yes | no
Hope the updates aren't too distracting ;) With luck you may be able to use some of the PolyMod 2 improvements in your project, depending on timing. I've been sketching out a way of upgrading from 8 to 64 modules without losing too much speed, will share my results in the new year!
Are you sure? yes | no
Spent a bit of time yesterday scheming out a slightly tweeked module design for my PM 1.2 and had a bit of a light-bulb moment when I reaised that changing the way that the mux are wired up from a vertical model (one function per chip) to a horizontal model (one function per channel across multiple chips) would speed things up by cutting down on the mux switching required. Is that what you are planning with your new PM 2 design?
Are you sure? yes | no
That's actually not what I had planned, but it sounds intriguing. Would be very interested to see a code sample or diagram.
My speed upgrade idea is based on port manipulation, using low-level read/write methods rather than digitalRead and digitalWrite, which are (apparently) quite slow. https://www.arduino.cc/en/Reference/PortManipulation
Sounds like there's no reason not to use both our approaches together, though!
Are you sure? yes | no