Size: 85
Comment:
|
Size: 4417
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
==== 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: [[https://www.muffwiggler.com/forum/viewtopic.php?f=16&t=68864|Muffwiggler: let's design a standard digital communication bus]] [[https://www.muffwiggler.com/forum/viewtopic.php?f=17&t=172723|Muffwiggler: digital modular system]] ==== 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: 1. MIDI_1.0 - 2. MIDI_2.0 - 3. RS232/UART - 4. SPI - 5. RS485/CAN bus - 6. Ethernet - |
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 -
- MIDI_2.0 -
- RS232/UART -
- SPI -
- RS485/CAN bus -
- Ethernet -