A few weeks back, we shared part one of our three-part series on building a modular company. We discussed our backgrounds, how the company began, and a bit about the things that have worked for us. In today's episode, we'll be chatting about programming, design, testing, and developing ideas. In the final part (coming soon) we'll discuss manufacturing and distribution.

I crave more details: on languages and programming skills

Stephen does the majority of our module firmwares (with Adam starting to do some too). Again, the advice here depends on what sort of products you want to build. If you want to do fully analog products, skip to the next section. If you’re interested in making digital things, this section is for you, but also learn some analog stuff because the two really go hand in hand.

Stephen is really skilled in DSP code because it's his background. It can be extremely math intensive (especially as generally taught in classes). Classes and textbooks tend to be mostly focused on theory with very little application. Becoming fluent in DSP is not a trivial venture, so if this is a goal, give yourself time! We lean heavily into Stephen’s expertise here in our products, but even after doing this for the better part of his life, he is still continually learning.

Most out-of-date DSP textbooks are just fine for teaching yourself from; Stephen also recommends the Julius O. Smith III books as a rare series we’re aware of that is filled with application, not just theory. These are available as free PDFs, but we have the physical books because they are really phenomenal references.

We do almost everything in C++, but early on when this was a hobby, Stephen wrote some of the firmware in assembly just for fun. There are no real rules here. We also recommend getting started with a platform like the Daisy Seed because it is open-source hardware. There is a whole community of users making things with it, which means there’s quite a support network, and options to use other languages to create your products. Grab a Seed and make something fun.

I crave more details: what about circuits?

Like DSP, teaching of circuits is all about theory. This is great but it won’t help you on the job much. The Make series has some fun project options, but they are pretty pre-baked. If you have zero experience, they are still a fun place to start and they will go over the most basic concepts. Once you have that much under your belt, pick a simple project and go make something. Don’t be afraid to make mistakes. Breadboarding is great, or you can glue things down on scrap wood chunks you have lying around, and get some solder practice. Soldering a module kit or two is also a bit more productive than soldering practice kits, though those also exist. 

Design 

When you’re ready to actually make a module, you’ll need a way to do schematic capture and create a PCB. These programs are called CAD (Computer-aided design) and there are a lot of options, particularly if you’re just getting started. KiCAD is free and open source. AutoDesk makes Fusion (which has subsumed a program called Eagle), and there are inexpensive options if you’re only using it occasionally. There are plenty of others, too, and they all do more or less the same thing, but once you learn one and have everything working in it, it can be a pain to switch to a different one. Because our world is flawed, some of these programs make it hard to open files from another program.

CAD programs also allow you to have parts libraries. If you’ve never had the pleasure of creating your own part in a CAD program, it’s one of the few parts of the job Kris actually hates. You’ll want a cleanly organized library of parts you use so you can pull from it to create your schematics. Then with the click of a button, a PCB is generated and you can start laying out your product. Wizardry! It’s important to have your parts set up properly here because what you lay out is what the PCB expects you to put there. If you source a through-hole resistor but put a SMD one on the PCB, it’s going to be hard to make that work.

How we do it 

We use Eagle mainly for historical reasons. Our first contract manufacturer used it, as does our current one, and just being on the same software helps us seamlessly send files back and forth. 

We have been doing this for a while and have released somewhere around 70 modules. This means we have a suite of circuits that we know work pretty well, so we often start just by pulling tried-and-true circuits together. We use a limited number of microprocessors and our own libraries so until we move to new CPU platforms, there’s very little unknown about the hardware part of most things (except when we make a giant mixer, for example). 

We have a general policy that anyone here can propose an idea for a product, but everyone weighs in. If you’re working solo, that may be harder to accomplish, but again, we recommend getting feedback from others… and making sure they will give you real feedback and not just what you want to hear.

On test

Currently Markus is our main Eurorack tester. They do a ton of other things too, but we’ve grown to trust Markus’s ear and instinct on most things. Once they deem a product sufficiently mature, we have at least one or two other folks on the team test. We test for sound, playability, layout, you name it. When we think we’re about done, we have one final person who hasn’t yet played with it give it a whirl. This is handy because sometimes there are regressions that no one noticed, and sometimes everyone is just fatigued and things get missed. Before production, we also do a test of all input and output voltages to make sure everything works as expected, check our reverse protection, and test it on a number of different power supplies. Then we have some people put the final firmware in a case and make sure we didn’t miss anything. It’s a laborious process, but worth it.

On ideas

We keep a whole GitHub repository of design ideas that didn’t make the cut, as well as fragments of ideas. Once a year we revisit them to see if there is a Frankenstein’s monster of a product to pull from the ashes. It’s rare, we’ve usually moved on to the next shiny thing (because we never have a dearth of ideas for things to make here), but a graveyard of ideas is a useful place to stick some ideas that may have been only half baked.