Build your own commercial module part 1: the design concept

2023-11-23 design panels byocm

There's a pretty natural progression in the modular synthesizer hobby (the addiction, if you prefer). People start out buying commercial modules; maybe they go through a few rounds of selling off modules that they find just aren't quite right; eventually, they come to the idea of wanting to build their own modules with exactly the features they want; and although doing DIY just for oneself is a viable hobby too, many hobbyists want to take the next step, of going pro and building and selling their own commercial modules.

There are regular threads on synth fora about how to get started in designing modules, and a lot of resources on the Web focusing on specific angles like op amp circuits, PCB design, or similar. It's also possible to hire me or another consultant to help you see your project through from start to finish, and in this next series I'm going to go over some of the general things I tell my consulting clients about commercial module development, especially focusing on design.

As often happens, I planned one article, then started writing, and almost immediately overflowed the amount of text that would fit in a single article. So this will be another series, of unknown length.

There are different ways to break down the overall process of designing a module, but here's one way. I'll go over each of these steps separately, along with some other points worth thinking about.

• Design concept: what are you building?
• Initial circuit: how does it work?
• Development: working out the details
• Physical design and PCB: how it fits together
• Firmware: intangible design
• Documentation: how to use the product
• Manufacturing: actually building it
• Selling it: making your product

When you're planning a module project you need to think about all of these things. I'll discuss the design concept in this article, and go on to others later in the series. If you have specific questions about a project of your own, you're welcome to send me email about it. Like most people who work on this sort of thing I can offer a free initial consultation without obligation, to sort out what the scope of your project is and how I might help with it.

Steps influence each other

I had to write the steps down on my list in some order, but an important feature of the design process is that the above steps all influence each other. There is a flow of information in all directions. As you work on each step, you will need to go back and make changes to others.

Often the "design concept" is a mock-up drawing of what the front panel will look like; but if you settle that firmly, then you've committed to a lot of decisions about the PCB layout and the physical design, especially how wide it will be. When you actually do the PCB layout and physical design, you'll either be limited by the earlier committment or you'll have to go back and change it.

In the stage I call "development," you'll often discover important things about which features work for users and which don't, which may end up resulting in drastic changes to the initial concept. Maybe you find you really want another knob for such-and-such feature, or that you don't actually need CV control over this other one and would rather have the chance to make the module smaller or cheaper.

Similar things happen at a lower nitty-gritty level in the circuit design. Maybe in the initial circuit you or your hired designer sketched in a TL074 op amp because that's a reasonably safe default choice; but then when you get to manufacturing you discover that your PCBA contractor can get you some other op amp chip at a low price, whereas the TL074 would be a more expensive special order. The designer looks at the data sheets and says yeah, the cheaper chip will work just as well; so you decide to go with that; but then you have to make changes to the schematic and the circuit board silkscreen to show the new part number.

Even without changing a whole chip, it's useful to allow the PCB designer a free hand for gate swapping, which means rearranging which unit within a chip is used for which function to make a better layout. That entails more schematic changes.

In a digital module, there can be a lot of gate-swap-like rearrangement between the circuit board design and the firmware. I spent a lot of time during development of the Gracious Host rearranging which pins of the microcontroller would connect to which other things, because of complicated trade-offs between the places where different hardware and software features were able to connect. The final results of that work are visible in places like the microcontroller pinout table in the programmer's manual, but exactly why each feature had to be placed where it is, was a much longer story not told there.

Some of the most important interactions are between the final step on my list, selling it, and all the rest of the design process. It costs at least a few thousand dollars to develop a commercial-grade module design. Most of us can't afford to drop that much money just to build one or two modules for our own racks (though of course I'm happy to get commissions from wealthy patrons who actually do want such a service). For the rest of us, someone seriously contemplating a commercial-grade design project is almost certainly planning to build the modules for sale and at least break even. In that case, how many you plan to sell, and at what price, makes a difference to all your other design decisions.

If you spend $5000 on a module design and you're only going to sell ten modules built to that design, it means you're going to need to cover $500 of design costs per module, on top of all the other costs of building the thing. Not many modules can be sold at a high enough price to roll an extra $500 into the price tag; so the sensible thing is probably to aim for selling more than just ten of them. Then the per-module cost of development is proportionally lower. The cost of development is a big part of why big manufacturers, who sell more units overall, are able to sell their products at prices small manufacturers just cannot match. And then that bears on how you, as a presumably small manufacturer, can compete: if you think your competitive edge is going to be "mine's the cheapest one," then you are setting yourself up to fail.

In the world of electronics, and synthesizers in particular, we are lucky to be able to work in such small volumes as we do; selling 100 units is a lot for Eurorack but a drop in the bucket of some other markets where nobody makes fewer than 10,000 units of a product at a time. And if you were in a market where you'd be selling 10,000 units of something, then the same $5000 development cost would be just $0.50 per unit, which paints a much different picture.

If you're contemplating a commercial module project then you need to have some idea of how many people actually will want to buy it; and then you also need to have some idea of what those people want from the module. It's quite possible you may end up having to make changes to the design to pursue a "lowest common denominator" that more customers will be happy to buy. It's partly because of manufacturers pursuing that lowest common denominator, that you find your own needs not perfectly met by existing commercial products. When there's a near miss with a module that is almost what you wanted but not quite, it's quite often because the near-miss design satisfied more people, and so it was more commercially viable, even if it wasn't exactly right for you or anyone.

You can save some money on design work if you can do most of it yourself and you don't count your own time as an expense. You can also, perhaps surprisingly, save some money by paying the money to me or someone like me for consulting services. A consultant can help you avoid going down paths that would end up costing you more time and money than the consultant's fee. But these are ways to keep the overall cost of a module design down to the thousands-of-dollars level; not really ways to get below that level.

What are you building?

The design concept is the answer to the question, what are you building? You presumably already know that if you're trying to build it, but at the start, the idea may exist only inside your own head. It's worth putting some effort into getting it out into the world in words and pictures. If you're going to hire someone to help you build it, you'll need to tell them what you want to build. When you try to sell the finished product then you'll need to tell your customers not only why it's a good product, but also what it is in the first place. So, answer that question!

People often start with panel designs. If that's what it takes to explain your idea, do it; but I think a description in words is often preferable because words make it easier to highlight what's important and what isn't. Incidental decisions like which knob goes where, and how wide something is, don't really need to be made right at the start, and shouldn't be - you should be making those decisions later, during "development" and "physical design" - but if you draw a picture, it is always going to imply answers to such questions whether they are really important parts of your concept or not. Stuff like the graphics on the panel can, and should, be decided late in the game - maybe not even by you, if you're going to hire a professional graphic designer - but drawing a picture means creating at least placeholders for those graphics immediately. Placeholders have a habit of becoming permanent. And beginners always draw the panel concept too narrow for the knobs and jacks they want to include. Writing down the concept in words gives you the opportunity to say exactly which points matter and leave out physical details except those you have thoughtfully decided are real goals.

After getting the basic concept down in a sentence or two of description, and maybe one or two sketches, you might start thinking about details of the concept. These often connect to technical requirements for the design, but it's important to try to state them as much as possible in terms of what the module does and how it's used, rather than how it does that. Figuring out how to achieve the goals is a later step in the design process, and if you're hiring a designer to help you, they can help you best if you listen to what they tell you about the how. Here are some questions that might apply to a Eurorack synthesizer module.

• What inputs and outputs does it have?
• If the module is "stereo" or otherwise contains more than one channel or instance of the same function, then how many channels or instances, what's the reason for choosing this number, and how important is the number of channels to the core concept?
• What features can be adjusted by knobs; what features can be adjusted by control voltages?
• When something is affected by both a knob and a control voltage, what happens if they are used together? Is the knob an attenuator for the CV, or does it function like an additional control voltage added to the CV input, or do they interact in some other way that is neither of those?
• What is your idea of the adjustment range of each feature, both for knobs and CVs? In the case of CVs, what should happen when someone applies an out-of-range voltage?
• What are the ranges of other parameters, like the frequency of a VCO, the number of steps in a sequencer, or the recording time of a looper? How important are these numbers to the core concept?
• When there is no cable plugged into a jack, what happens? Is normalling an important part of how this module is used? Even if it's not critical to the design concept, then given normalling is usually cheap to implement, is there a way normalling might make the module more useful?
• How precise are features like "unity gain," the cutoff voltages of things that clip, and tuning, tracking, and timing?
• Will this module have "expanders"? What's the reason for separating functions into an expander instead of having them in the main module? Is your module actually an expander for something else, itself?
• If you think this may be a digital module, then what is its behaviour with regard to saving parameters through a power-off? Will there be things saved automatically, and if so, which things? Will there be "presets"? If there are, then will some, all, or none of the presets be editable? Do you think "menu diving" is the Devil, and if so, exactly what do you think that term means?
• Do you expect that firmware updates will be a thing, for a digital module? Do you expect that alternative firmware will be a thing?
• Does this module need to interface with other systems that have defined connection standards, like USB, MIDI, OSC, I²C, Bluetooth, and so on? Is it supposed to interface to a DAW? To a cell phone "app"? Will it read Scala tuning files? Play WAV and MP3 files?
• Is this module supposed to imitate something else in particular, like the sound of a given "vintage" synthesizer, and if so, how exact does the imitation need to be?
• Does your design concept involve physical-design requirements, like maybe it's an electric string that can be played with a violin bow or something? Does your concept require a special control device, like concentric knobs, illuminated sliders, or a knob with a "click" (technically termed a "detent") in the middle of the range? Does it require special display features, like multi-coloured windows in the panel illuminated by RGB LEDs?
• Are you hoping to make it onto "List of SMALL modules 2023"?

There aren't necessarily single right and wrong answers to these questions; that's why they are worth asking. Sometimes the answers to small questions can make one product stand out from others. For instance, my MSK 015 Quad VCA, like many Eurorack VCAs, is designed to achieve unity gain at +5V control input. But unlike many, it is trimmed for that voltage/gain relation to be (reasonably) exact - not unity gain at 4.9V or 5.1V - which makes the module useful for some voltage-arithmetic utility tasks that most other VCAs couldn't do. And although clipping CV at unity gain is a common and reasonable choice, this one is designed to continue increasing the gain linearly beyond unity up to +8V control input. But it does clip at 0V instead of going four-quadrant, and in fact, it can be adjusted to clip to zero gain at a voltage a little above zero, which is useful for reasons best explained elsewhere. When the core function is a VCA, with hundreds of VCA products already on the market, there's some necessity to give it these little unique features to set it apart from other products. If the core of the design concept were something less popular, then the focus would shift.

The last few questions on my list, about interfacing to and imitating specific other things, and physical requirements especially on size, are often warning signs because they can be difficult and costly to implement. When I see such requirements in a design concept I think they'll usually mean trouble. But such things don't have to be dealbreakers. One good example would be the Teenage Engineering Pocket Operators which were all the rage a few years ago. The design concept for the entire line of products is basically just "standalone synthesizers with custom LCDs." Getting a custom LCD made is an expensive and complicated proposition that might be seen as a dealbreaker for many products. But the designers at Teenage Engineering had the insight that if they went ahead and spent the money and effort to actually use custom LCDs, and then covered it by cutting costs on basically everything else, they could make it work. And it did work; the resulting synthesizers were a hit, including among customers who weren't part of the general synthesizer hobby. The real key is not "never have such requirements" but "understand what the important part of your design really is."

Beware the kicker

Sometimes a design concept includes what I call a "kicker." Somewhere on the list of requirements, most of which are easy, or hidden in the answer to one of the questions above, there'll be one point that is not like the others. The kicker changes the entire scope and nature of the project. It's one seemingly small thing that, if treated seriously, will cost you more time, money, and annoyance than everything else on the list put together. Beware of writing kickers into your design concepts!

My best example for a kicker in a development project is actually not from a synthesizer but a Web site project I was once asked to quote on. The client sent me a three-page document describing what thought they wanted, and as I read it it all seemed straightforward and I thought I had an idea of what it would cost to build, until I spotted something near the bottom of page two that said the whole works had to be written in a specific version of Javascript.

Well, up to that point I had thought we were talking about writing an interface between the Web site and a large existing software system that happened to have been written (decades earlier, not by me) mostly in FORTRAN! The interface probably would include some Javascript but I'd thought the legacy system it touched would remain basically unchanged. If the client really expected to have the entire final system written in Javascript including the back end, then instead of just creating an interface, I'd be translating all the FORTRAN, at somewhere between ten and one hundred times the cost of the project I'd first imagined. And I think the requirements document didn't even use the word "Javascript." Whoever wrote it hadn't seriously considered the possibility of software not being entirely written in Javascript. They thought the important part worth mentioning was just the fine detail of which version of Javascript it would be.

That is the characteristic pattern of a kicker. Whoever puts in the kicker doesn't think it's a big deal, maybe doesn't even think it needs to be mentioned directly or thought about consciously. But for being a minor detail it ends up having make-or-break, order-of-magnitude, consequences for the entire project. Another part of the pattern is that the kicker is usually a technical point: not the user-visible goal that the project is meant to achieve, but a requirement to get there with specific tools and techniques. The kicker may often be a number, like "24 bits", or even just a single strategically-placed word like "passive".

It's important to recognize kickers and be willing to explore other options when they turn up. That's something I or another consultant can help you with, even during a free initial consultation. Ask your helper, are there any details of this project that are going to become big obstacles, and are there ways to remove those obstacles while maintaining the really important parts of the concept? If you're proceeding alone, you can ask yourself those questions, too.

In the case of the Web site, I wrote back to the client explaining that I thought the Javascript thing was going to be costly out of proportion to its real importance, and would bear heavily on the success or failure of the entire project, so they should think hard about how important that really was to them. I tried to lay out several different options with accurate projections of their likely consequences, including putting the old code on a separate server with Javascript to talk to it; really doing the complete rewrite; doing a selective rewrite of just the subset of features they needed to call from other Javascript code; and so on. Exactly why they thought they wanted everything in Javascript would make a big difference to which option made the most sense, so of course I asked about that too. I also factored in the possibility that I had misunderstood what they'd written in the requirements, and they really only meant that any Javascript parts of the system had to be in the version they had named.

After I wrote the email flagging the Javascript requirement as a kicker, I never heard from that client again. Fortunately, they didn't owe me money, so I could just walk away from the situation. Unfortunately, it meant they almost certainly had to abandon their project, because nobody else would have been able to give them a more encouraging truthful answer. In order to proceed further, they would have had to think hard about their kicker requirement in a way that I guess they weren't willing to do.

The options for dealing with a kicker requirement include saying "This is really important and we will pay what it costs to actually do it." They also include abandoning the project because the kicker requirement is infeasible. But there is almost always a middle path, too - one that doesn't take the kicker at face value but looks at why that requirement ended up on the list, and what's the best way to achieve whatever is the really important goal there without endangering the entire project. And that is my excuse to plug the otherwise unrelated MSK 013 Middle Path VCO, which is the kind of module I can help you build. Your support of my business is what makes it possible for me to provide resources like these Web log articles at no charge.

◀ PREV Delta-sigma DACs and CODECs || Build your own commercial module part 2: design and development NEXT ▶