Eurorack modular producers fall on a spectrum between design-driven and customer-driven. Design-driven producers mainly pursue their own, opinionated design philosophies and interests, and tend to ship finished products. Customer-driven producers apply their general technological expertise to what they hear from customers, and are sometimes prone to offer open-ended products with final hardware but evolving software, or they otherwise intentionally build in leeway for software tweaks based upon market feedback. Producers like Make Noise and Verbos are more at the design-driven end, while Expert Sleepers, Happy Nerding, or maybe Ladik are perhaps toward the other. A company like Noise Engineering might be somewhere around the middle, at least part of the time. There are probably far more design-driven producers than customer-driven ones, but the latter can attract a lot of attention.
Except for non-shipping prototypes, I’m talking about modules with microcontrollers and updatable firmware. The unthinking presume that—like a personal computer—the sky is the limit with software updates to such modules, so anything goes, because: WHY NOT? The notion that software updates are the default solution to obstacles in a modular synthesizer—rather than creative patching, embracing and exploiting limitations, or even buying another module (or three, and a new case, if necessary)—is what I have begun calling The Disting Effect.
The Disting Effect can get nakedly egregious, such as the feature request on the Five12 forum for the Vector to reproduce Pamela’s New Workout functions on the Vector’s jack expander. Because, WHY NOT? The Vector is, after all, a “work-in-progress” product, and customer feature requests are solicited. Another egregious example (from MW) was a spasm of outrage over the revelation that XAOC’s Odessa doesn’t have easily-updatable firmware so that new features could be added “in the future”.
For one thing, microcontroller-based modules are not all equal. A few—the Disting EX being the purest and most prominent current example—are specifically conceived to be extended through software updates over many years. The open ended-ness of Disting EX is a remarkable thing, but it is uncommon in embedded systems. Indeed, the Disting EX stretches the idea of an embedded system nearly into platform territory. (If these terms are unfamiliar, don’t worry about it and read on.)
In constrast to the Disting EX, most Eurorack modules with microcontrollers are already pretty tapped out, with little available overhead in processing or memory beyond what was allocated for the module’s purpose. Most modules are designed to do specific things, and their physical parts were chosen accordingly, hopefully employing good business acumen. But there are many other potential reasons WHY NOT, and they will vary somewhat depending on where the producer falls along the aforementioned spectrum.
Here’s a subtler example, which I will recycle from a recent discussion on another message board:
A fan of the Make Noise Tempi found themselves wishing they could add their own gate sequence patterns to Tempi, in addition to the 50% duty cycle clocks that Tempi now produces. How nice if you could enter your own pattern of gates and rests, and have that pattern live inside Tempi alongside the clocks, enjoying the same interesting Tempi clocking features?
Sounds great! Indeed, WHY NOT? I don’t represent Make Noise, but I can conjecture more than a few reasons:
- Tempi is a clock module, not a gate sequencer. Adding gate sequencer functionality alters, dilutes, and confuses the identity of Tempi as a product.
- Tempi is a finished product. It’s done. It does what it was designed to do. Make Noise has moved on to new products.
- Various gate sequencers already exist that can be clocked by Tempi, and Make Noise is not interested in adding new functionality that is readily available elsewhere, or “me too”-ing features from others’ modules
- A new mode for step entry is proposed, but there’s no physical interface, whatsoever, to support that mode (perhaps a good enough reason on its own)…
- … so it would have to be a hidden mode, relying on some obscure button combinations; that has to be documented, and it takes an already dauntingly opaque module and makes it more so, potentially driving away potential customers
- … and existing customers would inevitably enter that mode by accident and screw up their performance, and now they’re angry customers
- In addition to being a standalone product, Tempi is a component of the Black & Gold Shared System, so all these reservations would also apply in their unique way to that product
- Moreover, the idea isn’t actually thought through: how is the new mode entered? How is it exited? How you do clear a sequence or return the channel to regular operation? Indeed, what about reset—how does that work? What about gate length? (After all, there’s only one mod jack which is arguably inadequate for the Tempi’s existing functionality.)
- There may actually not be sufficient memory or processing available in the Tempi hardware to add all this stuff once it’s sorted.
- As a business proposition, what is the up-side? Will Tempi sales double because of this new feature? Probably not. So it becomes a question of shifting away resources to gratify a minority of customers, while potentially introducing new bugs, adding new confusion about an already-confusing product, handling a spike of customer service problems with people having trouble updating their firmware, and generally encouraging the problematic notion that customers are entitled to endless firmware updates to add unplanned features to modules that happen to have firmware! Doubling sales of Tempi might not be enough to justify the effort.
- What would it actually do, what would it NOT do (Achilles’ heel), and how would it actually work within what’s already there (both hardware and software)—you don’t have to have all the answers, but if you cannot clearly express yourself, you’re just going to waste other people’s and wind up in the weeds
- Consider whether the need you’ve identified can already be met through patching other common modules—if so, then your case is tenuous, at best; if the patching workaround would require a dauntingly large number of modules, then your case might be strong
- Consider whether the functionality would really benefit the customer base at large, or whether it’s really just a convenience for you—a few module designers may be into adding niche functionality to their products, but the vast majority are clearly not
- Related: consider whether the functionality and the changes it implies would make the product stronger and better at its core purpose, or whether it would dilute the product and its identity—you can always try to patch an apple like an orange and work with the results, but don’t make demands that an apple actually become an orange without an exceptionally compelling reason
- Consider whether the functionality and the changes it implies would make learning and using the module more challenging: new things to learn and remember, additional steps to navigate, and potential traps (hidden modes to get into by accident and not know how to get out of)—changes have the potential to actually hurt current and future customers more than help them, all product features come with a price of some sort, and it adds up fast
- Don’t act entitled—sapping the joy that module producers get from what they do will not get you more of what you want
- If you’re a relative neophyte to modular synthesis, recognize that you probably lack the knowledge and perspective to be proposing compelling new product features—focus on learning more patching techniques and exploiting the limitations of your system, rather than seeking software solutions to the first obstacle your id encounters