Digital Control ideas for Modular Synths
Motivation
Modular synths are increasingly coming out of the studio and into performance settings, and not just for experimental music. For pop, rock, and even dance related genres, the ability to switch context quickly between songs would expand the range of use for modular synthesis. The ability to "recall state" would allow the capture of the often fleeting moments in modular exploration where an expressive or unique patch is created. To accomplish this, many things are required: digitally addressable and controllable modules, a "patch" sequencer of some sort, a digital communications standard, and a way of digitally repatching. Not all of these things currently exist, or are perhaps even wanted. For some discussion on the relevant pros/cons of these systems, and the technical limitations, here are a few forum posts:
Digital Modules
In the forum posts above, the lack of digital control is cited as one of the main road blocks to patch recall. If there are no modules to control, what's the point of a digital control standard? But, some of those posts are almost ten years old at this point, and modules with a microcontroller in them are now quite common. The tasks these micrcontrollers perform range from UI control (reading pots/switches and changing LEDs/displays), CV generation, LFO and envelope generation, full sound synthesis, and sequencing. Any of these tasks could be globally stored and recalled. And, although there is a "chicken and egg" problem involved, no progress will be made if no one works towards a solution. If a single manufacturer created an eco-system of products that enabled this control, and open-sourced the protocol and hardware, others might choose to opt-in as a way of increasing sales for a small increase in development costs.
Patch Sequencer
There are many forms this module might take, and i will merely sketch out a few ideas here to set the background for how such an eco-system might work. The main task would be to querry the connected modules for their state, and save it in a menu system of some sort. These could be written to flash cards for ease of transportation or computer composition. There could also be real-time record to save certain knob movements (for example) and automate repetitive performance aspects. A global clock signal could be sent to all modules, and sound generation and parameter changes would be synced to this clock. If the conrolled modules reported human-readable parameters, these could be shown on a display for editing.
Digital Communications Standard
This is often seen as the bottle-kneck for the creation of this kind of system, although i would argue that the "chicken and egg" problem stated earlier is the real issue. Having access to the internet wasn't that useful when no one else was on the internet. We already have a number of communication standards that could be shoe-horned into service here, but none are ideal. General requirements would be: low cost (<2$ of added hardware cost), easy and cheap access to cables and jacks, bi-directional, high data throughput (~1Mbps), tolerant of mispatching, and simple to work with on a code level. This communication could either be through front-panel connection, or a back-plane connection. The former would be more versatile, and allow patching across rigs, but the latter could be higher data rate. A third option would be wireless communcation over 802.15.4 or WIFI. This would probably only work as a front panel antenna system, as not all modules are designed to be robust against RF interference. But, the RF power level could be quite low, as it only has to go a few inches, but back-plane RF would also make inter-rig communication difficult for entirely metal enclosures. Just from a cost and ease of implementation perspective i would not select a wireless method as the main mode of communication. Some possible options are:
- MIDI_1.0 - A good standard that is simple, inexpensive, and already well adopted by the music community. But, it is slow and not bi-directional. A second MIDI network could be used for the back channel, but then MIDI mergers would be required at each node, and they may not be able to handle the network traffic. A modified MIDI back channel could be used (see below).
- MIDI_2.0 - This fixes a lot of general complaints with MIDI_1.0, but seems focused on USB MIDI, which does not help in this case as a USB hub would be required on each module to daisy chain the signal. You can run MIDI_2.0 over the 1.0 hardware standard, but then you lose the bi-directionality and speed improvements. This is more costly and complicated option.
- RS232/UART - This is basically what MIDI runs over, and is a generic physical layer that does not require syncronous clocks between nodes. It is inexpensive, simple, and bi-directional, and can be used at speeds up to 1Mbps. It would require a custom protocol to be designed.
- SPI - This is very robust, fast, inexpensive, bi-directional, and simple. The downside is that it requires a clock and chip select line. This would be a fine option for back-plane communication at speeds in excess of 1Mbps. i have used SPI on runs of over 20', in noisey environments, with no problems, and only using the microcontroller's onboard I/O drivers. It would require a custom protocol to be designed.
- I2C - This is a slow and unreliable form of communication that should only be used on runs less than 4". It also requires a clock, and is only half duplex. It would require a custom protocol to be designed.
- RS485/CAN bus - These systems are similar to one another, and to RS232, with the exception that RS485 and CAN bus are designed to allow for MIMO networks. This, along with the differential signalling (and associated reduced EMI) make them a strong option. CAN bus is probably a bit heavy on protocol, and RS485 does not specify a protocol, so something new would probably need to be designed.
- Ethernet - High data rates, but expensive and power hungry. i mostly have it on the list for completeness sake. OSC can be run over ethernet.
