Hannes
In the second part of this series we have seen how open source has worked for some of the module makers on the market, but what about us, the so called “end users”? In what way do we profit from all of this?
Skilled users can modify the software/hardware to better suit their needs and distribute these modified versions, so other people can use them. Other makers can improve their own products, by taking advantage of open-sourced technology. There’s a bunch of virtuous circles that that arise from these dynamics, which ultimately coincide to improve the modules’ functionality.
Just to name an example, recently 4ms used Mutable Instruments’ bootloader code on their SMR module, and released the SMR’s source code under a MIT license. Mutable Instruments’ bootloader let’s you update the module’s firmware via an audio file by playing it into a CV input, which makes the whole process a very easy and straightforward one.
Many open source modules have seen alternate firmwares or modified designs getting made by the community, down below in this article we’ll be looking into some modifications of Mutable Instruments’ modules and talk to two known firmware modders: Tim Churches and Matthias Puech. But before we get to that, let’s hear from some of the other makers about their experiences.
Brian Crabtree (Monome):
There is a great alternative firmware for the White Whale module, written by scannerdarkly. It has a different take on a sequencer, a total branch from the original idea and hence doesn’t make sense to roll back into the main version. But the Aleph is fully open, and there are numerous contributions that find their way into the main codebase– the Aleph really is a community-driven sound computer at this point. And the grid– honestly it’s so simple that there’s not much to do or add. There have been various rallies for multi-color and velocity but to me those are totally different devices.
Software for the grid, however, is a total free-for-all. There has been so much cross-pollination of ideas and features for grid-based audio applications that constructing a sort of family tree would not be a trivial task.
And Teletype is just starting to get momentum. It’s the perfect platform for someone to decide they want a new specialized command and just add it in– and quite likely see it in the next official release. It’s a very exciting little ecosystem.
Orca firmware for the White Whale module: github.com/scanner-darkly
Andrew Ikenberry (QuBit Electronix):
[…] people have modified Nebulæ code and reposted it online. We have a page on our site that contains all of the alternate code that can be run on the Nebulæ: www.qubitelectronix.com/alternateinstruments. There is also a really great thread on MuffWiggler that people usually upload their new code to to get feedback, advice, and to share their creations: muffwiggler.com
Manu Retamero (Befaco):
There were a few improvements in newer versions of our modules that were pointed from users. I myself started attending the workshops and now I’m a member of the crew! Also, people from #T37 in Madrid (where we do our workshops) are hardcore DIYers, lovers of Banana plug and they usually do their own panel versions, mods and front panels.
Tom Whitwell (Music Thing Modular):
Circuit Shaman has done that with Bytes and Switches, he should have published his modules CC-BY-SA, not sure if he has.
I really love that customer service / help has become distributed. I see people popping up on Muffs, or in the Radio Music Github, with questions and someone else replies or gives them help before I see it.
I like that people can take the circuits and use them – if they want to put a spring reverb into a project, they can use mine, for example. I love it when people make 5U versions of stuff.
A few people have taken my Turing ‘algorithm’ and done versions as software or within digital modules (I think there is or was a turing-inspired mode in the Abstract Data Octocontroller) – that’s really nice but not relevant to the license because they’re just inspired by the idea – it’s not like I could patent the idea of a shift register with a randomly inverting feedback loop!
Bytes and Switches Turing Machine expander: www.mysticcircuits.com
Alternate firmware for the Radio Music module: github.com/TomWhitwell
Martin Klang (Rebel Technologies):
We have lots of user contributions, but not so much to core firmware. Writing embedded firmware is quite a specialised skill. Writing patches, contributing to the client tools, and web development is much more widely practised.
I’ve seen some beautifully made clones of some of our modules, that have been done based on the schematics and photos. But from what I’ve seen, so far, they replicate the functionality rather than modifying or extending it.
Alternate firmware for Mutable Instruments Modules
Two firmware modders became quite famous among modular users for their alternate softwares: Matthias Puech with his Clouds, Frames and Tides Parasite firmware and Tim Churches Bees-in-the-Trees for Braids and Dead Man’s Catch for Peaks.
Mutable Instrument’s Olivier Gillet (who btw. released his own alternate firmware for Tides called Sheep, which turns the function generator into a powerful digital VCO) is very happy with these mods:
They are great! I have a threshold on the level of complexity/depth I tolerate in a module (which is already quite high), but I agree it’s very personal and arbitrary. It’s a good thing that people are trying to go further than I did, and in the process release “free modules”, because it’s really what it feels like when a firmware update adds a completely unrelated function to a module. It can actually help people try new types of modules they didn’t know they wanted… like someone trying the “Turing Machine” through Braids’ alternate firmware, loving it and actually buying the actual module that inspired it. It’s really hard for me to find a reason why free modules – even with difficult to use UIs – would be a bad thing.
He even incorporated portions of Bees-in-the-Trees in a later official firmware update:
People seemed to like the triple sine/triangle models from Bees in the Trees, so I put these in the official Braids firmware too. The biggest “payback” I get from the open-source is not so much the code from the other developers, as hints about what to do next. It’s a good sign when people ask for a module centered around an idea born in an easter-egg or hacked firmware!
If you want to try them on your modules, here’s some links to get you started:
Bees-in-the-Trees for Braids and Dead Man’s Catch for Peaks: timchurches.github.io/Mutated-Mutables
Sheep for Tides: mutable-instruments.net/modules/sheep
Clouds, Frames and Tides Parasites: mqtthiqs.github.io/parasites
But let’s get deeper into this, as previously mentioned, we had a little talk with both Tim Churches and Matthias Puech.
Tim Churches
Interview with Tim Churches
Horizontalpitch: I think you were the first to make a big alternate firmware for a MI module (I think it was the Bees-in-the-Trees firmware for Braids) or am I wrong?
Tim Churches: Yes, Bees-in-the-Trees for the Braids module. A few people reported they had made minor changes to Olivier’s code, but I think Bees-in-the-Trees was the first one to share its code under the same open source licence that Olivier uses, and to document the modifications thoroughly.
HP: Why did you decide to mod the firmware in the first place?
TC: I had been discussing adding MIDI capabilities to Braids with Michel Morin (aka Sneak-Thief) who is in Berlin, and we both started to look at the Yarns and Braids source code. The MIDI modifications were put on hold, but I realised that it would be quite easy to re-purpose the internal envelope generator in Braids as an LFO. Then I got a bit carried away and over the next few months added a lot of extra features as well.
HP: Some of your features then landed in the next official firmware update (I’m thinking about some of the 4-voice modes), how did that happen?
TC: I think Michel Morin implemented a triple sine wave oscillator model, which spurred me to add a few variations on the wavetable models. I think Olivier looked at our code and decided he had better implement those oscillator models properly! So those two new oscillator models appeared in the next official Braids firmware update which Olivier released. Following that, I had an email conversation with Oliver about some minor changes to the official Braids firmware so that it could more smoothly co-exist with an ecosystem of alternative firmware images, resulting in Olivier releasing version 1.7 of the official Braids firmware.
Postscript: Olivier has just released a further update to the official Braids firmware (v1.8), which adds some capabilities that were clearly inspired or informed by features in Bees-in-the-Trees, such as a wide range of scales for the built-in quantiser, and separately settable envelope parameters, rather than just preset envelope types. I think that’s an example of the “virtuous spiral” which open-source licensing creates: code and ideas are borrowed to create an upwards cycle of improvement, sometimes between products that may even be competitors, but nonetheless to the benefit of everyone.
[…] Given the enormous advantages of digital modules, at least for many purposes, I think we will eventually reach the point that smaller module manufacturers who do not join this nascent open-source firmware “economy”, in which both individual hackers like myself and companies like MI and 4MS participate, will just get left behind.
HP: What’s this thing with the naming? Your alternate firmwares (and Olivier’s Sheep) all reference Greenaway, did Olivier start with this or did you?
TC: Olivier started it by naming his alternative firmware for the Tides module “Sheep”, which is a reference to one of the whimsical games played in the film “Drowning by Numbers”, directed by Peter Greenaway. Both Olivier and I are clearly fans of Greenaway, so I took up the cue and named Bees-in-the-Trees after one of the other games that feature in that film. In fact, if you look at the Wikipedia pages for the film, you’ll even see these references mentioned! I’m now working on alternative firmware for Peaks, and that is also named after a game in “Drowning by Numbers”. I even incorporated the name of one if the characters in the film as an extra setting in Bees-in-the-Trees. The Michael Nyman soundtrack to the film is wonderful, BTW.
HP: As far as I know you also made an alternate firmware for Peaks, any other mods planned?
TC: Yes, lots of plans for additional modes and features in Dead Man’s Catch, for Peaks. Unlike Braids, there’s quite a lot of spare storage space in Peaks, so new features can be added without having to sacrifice any existing capabilities. The limiting factor is really the user interface. Lots of experimentation is typically required to arrive at a workable means of accessing additional features without resorting to hard-to-remember sequences of button presses.
HP: Have you learnt anything by working on the Bees-in-the-Trees firmware?
TC: Yes, apart from learning a lot more about C++ coding (I am a health researcher, and usually code in high level languages such as Python and R), and about developing for embedded devices, I have realised that releasing code for the modular community is a bit different to the usual open-source development process, in which the mantra is typically “release early and often” – that is, all the development occurs “in the open”. I found that doing that while developing Bees-in-the-Trees didn’t work very well: many modular user who volunteered to test the code weren’t expecting updates every few days, although that would be common practice in other avenues of open source development. Also, you need to be very careful not to “brick” end users’ modules, and thus careful testing is required before every release, even of intermediate and development versions. Luckily, as far as I am aware, no modules were rendered unusable during Bees-in-the-Trees development (although such “bricking” is always recoverable, but not necessarily by the end user), but it did keep me awake at night for a while. Thus, having a team of testers who are willing to run the small but definite risks associated with testing development firmware code is really important. I was lucky to be able to recruit such a team of around a dozen people for Bees-in-the-Trees development, via the MI forum web site, and they provided tremendously useful feedback, bug reports, as well as suggesting some fantastic ideas and features which I incorporated into Bees-in-the-Trees. Having such a community to help with testing and to steer development for each and every firmware hacking project is vital, I think, and I owe all those who participated (too many to name here) a real debt of gratitude
HP: What do you think the future holds for open source synth modules?
TC: It is clear that many new modules will be digital, or at least be digital/analogue hybrids. For such modules, relying entirely on control voltages, analogue triggers/gates and analogue potentiometers seems a bit limiting, and definitely drives up the cost and size of such modules. Analogue patch cords are also just single channel, and there is a physical limit to the density of patching before a modular becomes an ergonomic nightmare. For these reasons, I think that some form of digital buss or communication channels, which will allow digital modules to talk to each other more efficiently, is inevitable – not to replace analogue control voltages, but to complement them. Several manufacturers have or are about to release such digital control subsystems, but so far, they all seem to be proprietary, each unique to a single manufacturer, or to a small group of collaborating manufacturers. What is really required is a free, open-source standard (and reference implementations) for communication between modules from disparate manufacturers and designers. Of course, it s not at all clear what form such a protocol should take, and what capabilities it should support, which is why it is so important that it develops under an open-source licensing umbrella, to allow it to grow organically. I am pretty sure we’ll see such a development in the next few years, and it will be interesting to see which module manufacturer or developer will be the first-mover in this respect – you can probably guess who I hope will do it first!
Matthias Puech
Interview with Matthias Puech
Horizontalpitch: Tell me something about your background, you obviously know a lot about programming?
Matthias Puech: I am a computer scientist by profession (or at least I try to be). I did my Ph.D. in a theoretical branch of computer science that is at the intersection between programming language theory and mathematical proof theory. People in my field of research are not necessarily programmers, there are more often mathematicians or even philosophers, but I was always interested in the meeting point between dirty hacking and beautiful theory. My big scientific credo, which I think could apply to other domains of knowledge, is that there is necessary a cross-polinization between well-behaved theory and day-to-day practice. It’s not only in the natural direction people think of first, that is, applying a theoretical framework. That’s a big missed opportunity and I enjoy reading what seems like dirty hacks that saved the day and reinterpret them in the light of established theories. I could go on, sorry; you can cut this paragraph if it’s too long and off-topic 🙂
So yes, I know a bit about programming, but I didn’t know much about DSP when I started the Parasites. I always had a steady music output, and was always interested in innovative music technology; I did a bit of Max/MSP in my young years, went to IRCAM a few times for trainings, missed an internship at GRM (a big regret)… But it’s been really fun learning all this stuff properly with the goal of this project.
HP: Do you develop your own modules?
MP: Nope. I’m just an enthusiast looking for new things to learn. I don’t plan to develop my own module line, I’m not really attracted by the hardware side of things. But I’m open to collaborations!
What is great about Mutable Instruments modules, and all open-source platforms for that matter, is that if you have the technical skills you can use them as completely blank canvas: empty hardware shells to prototype ideas, try new things, and maybe eventually come up with a finished project that completely turns the hardware upside-down. And you don’t have to go through the painful hassle of making a PCB, assembling… just choose the module with the right number of pots/CV/input and the fitting hardware limitations and you’re good to go!
HP: When and why did you come up with the idea of modifying the Clouds firmware?
MP: It was purely out of frustration. It can seem weird, but frustration has always been a powerful driving force for me. After buying my MI Clouds, I got really excited—like most people, it is really a game-changing module—but I was quickly annoyed by a few minor details which didn’t fit to my personal workflow. There were also simple features I was missing, like an independent reverb, or a more fully-featured delay; my system is fairly small so I have to make the most out of each module; especially, unused functions/pots/inputs really hurt my OCD 🙂 So it all started as a way to fulfill my personal needs, to make music; I though I would share my work, since it could be useful to others too.
That escalated quite quickly: when I realized that I had invested the time to delve into the source code and that I could do much more, I began working on my own modes. It’s been great and I don’t regret anything, but my music output has been quasi-null for the past few months. Damn you, rabbit holes!
HP: Your modified firmwares add even more features to already very feature-packed modules. Aren’t you afraid of adding too much complexity?
MP: No, but yes.
The enthusiastic geek in me wants to answer immediately: not afraid at all. First of all, this project is all about fitting my own musical needs in the first place. This is why it is free: if you like it, use it, otherwise just keep the stock firmware. Secondly, complexity is not necessarily a bad thing. A modular synthesizer is itself a complex contraption full of endless possibilities, that is why we love them so much. To me, the added benefits clearly make it worth the mental investment of remembering a few keypresses and knob functions. Finally, let me argue that it is not that complex: I tried as much as possible in my alternate firmware to have a clear user interface that separates several modes, which work like several totally independent modules inside one box; “all” you have to do is remember how to switch modes, and what knob does what in each mode.
But I reckon that there is a bit more to this question of complexity and added features versus ease of use and immediacy. There is actually an ongoing discussion on Muff Wiggler about this, where I am taking the extreme position above, but let me be a bit more tempered here. The modular synth sits in a quite magical spot in the spectrum of human-machine interaction: it is hands-on, yet very rich and deep, and above all: so much fun. Technology allowing, especially with the advent of purely digital modules, much is possible but we should be careful not to burn our wings. A lot of us wigglers got away from their computers to make music exactly because of the complexity, freedom and therefore loss of focus that the computer brings (to make it simple). The restricted environment of a modular synth allows to be so much more focused and creative, it is really surprising and inexplicable! This state should be somehow cherished and preserved, I admit. One really bad thing that could happen is for example that each and every digital module could perform almost all possible tasks with the right program (“I want to run two Braids and three Turing Machines on my Elements”). The next step would then be to add a screen, a keyboard and a mouse, and we will have gone full circle! On the contrary, I love the idea that a few makers present us well-thought, carefully chosen sets of functions on dedicated, especially designed hardware. In a nutshell, it is a delicate balance, and I don’t have a clear answer. But god, it was so tempting to cross the line carelessly…
HP: Do you think all modules should be released with an open license?
MP: Again: no, but yes 🙂
I realize that this is not necessarily for everyone: as a maker, when you invested R&D time in the development of a module, you might not want to share it with all your competitors. You might even not be excited by the idea of random users modifying your own creation in ways you might not agree with conceptually. If you decide to open-source your hardware too, you’re even exposed to people making DIY copies of your modules without you benefiting financially from it at all. These are all perfectly valid arguments.
But there are two reasons that, to me, largely outweigh these. The first (and I agree with Olivier from Mutable Instruments on that) is that publishing the code is a strong sign of intellectual honesty, that surely customers are sensitive to. It means that you are not hiding anything about the technical inner-workings of your products behind marketing nonsense, which is so often the case in the music tech industry. It means that you are willing to let the whole community benefit from your work, therefore constantly raising the bar in terms of quality and innovation. Your advantage as a maker is that you then have the know-how, and these few months of advance R&D-wise with respect to the competition, so you are still attractive to customers (again, this is almost quoting Olivier, but it’s a standard argument in favor of open-source). And I am not even talking about the benefits of possible alternate firmware developed by the community… Secondly, do not forget that publishing software or hardware on an open source licence is not giving away your findings for free! You still own the intellectual property on them, and reusing them is legally very restricted and framed: for example, you have to explicitly cite the original author; depending on the particular licence (there exist dozens), you might even be legally obliged to release your own source openly (this kind of clause is colloquially called “contamination”). Finally, a direct way to take advantage of this situation is to charge for technical support: one could imagine other makers paying a monthly subscription to get advices and explanations about your code. To sum it up, I think that it definitely gives more work to the makers and they have to somehow renounce to some of their “artistic pride”, but these concessions are largely paid off by the momentum you are creating around you.
I have on good authority that more and more of the major players in Eurorack are thinking about releasing their source code and hardware openly. This is great! Eurorack is a small, cottage industry that would make a perfect bed for this business model. And it would also surely give a lot of exposure to our little community even outside of music tech if we were to build this island of commercially successful, open-source products!
Coming up next
In the fourth and last instalment of this series we’ll take a look at the Black Market Modular Colours Palette and it’s parent, the DIYRE Series 500 module with the same name. It’s a great example of how an open source project can grow further.
—
Cover photo by Tim Churches
