As mentioned on this prior post, the ISHIZENO i8 is going through yet another round of design changes. It is certainly not the last one, but I hope to stay on this particular path for a while, at least long enough that I can show some real pieces of hardware that we can play with and learn from. Before I explain what changed, let me outline what did not change:
- Eurorack module
- Submodular design (proprietary interconnect)
- Polyphonic (8 independent stereophonic voices)
- Powered by embedded Raspberry Pi 2
- Controlled through web-based graphical user interface
- Digital control of analog audio signals
- Dynamicaly-assigned rotary encoders
- Multi-channel level visualization
- Dynamic patching
- Stateful settings
At first sight, it might look like not much was changed. And to a certain degree, this is true. Overall, the spirit of the design was largely preserved, at least as far as the original intent is concerned. But from an implementation standpoint, pretty much everything is different, from what the faceplate will expose, to the way CV levels will be processed, and to the core set of components that might be used. Let us review these changes in details.
First and foremost, we have decided to reduce the number of ports exposed on the faceplate. To be honest, our latest iteration went way too far. 128 jack chassis sockets on a 42HP module is simply ridiculous. How did we get there? By requiring that each of our 8 channels (aka voices) should have 16 CV ports. Granted, the arithmetics are correct, but nothing else about this decision was. Instead, we should simply realize that faceplate ports could be dynamically patched to submodule ports, and that 16 to 32 faceplate ports should be enough. And if more are needed for a particular application, a companion module could be added for them. Therefore, we have decided to go for 16 inputs and 8 outputs.
Digital CV Modulation
From there, we should move from the analog domain to the digital domain, and most of our backplane should be digital. In particular, all CV ports should be converted into digital signals right away, using 2 analog-to-digital converters with support for 8 channels and 16-bit resolution (AD7606 or ADS8568). Moving CV modulation from the analog domain to the digital domain would bring many benefits. Among them, I would note:
- CV patching with software instead of switches
- LFOs, envelopes, and clocks with software
- Summing VC levels and knob settings with software
- Implementing custom knob response curves
- Normalizing the input of empty ports
By default, a submodule should be implemented with 100% digital signals, using a single DSP. Simple submodules could be implemented with the STM32F405RG, while more advanced ones could use the ADSP-BF533. In order to do so, the backplane should provide a multi-channel Codec like the 8-channel CS42428, which provides 24-bit digital-to-analog conversion at 192 KHz. As a result, a digital submodule designer would not have to worry about dealing with mixed signals, CV patching, control settings, and D/A conversion, and could build a very capable submodule with a single chip. The interface between the backplane and a submodule would become very simple and would be limited to a single SPI interface (for sending and receiving 16 control signals at 4 or 8 kHz), and one I²S I/O (for sending and receiving 2 channels of audio at 96 kHz). This should be the default option for creating a submodule, and it could lead to the development of digital submodules that could retail for less than $100.
As a future extension, it should be possible to develop an analog submodule as well. For that purpose, an analog slice could be added between the backplane and the analog submodule, in order to facilitate the work of the submodule designer. This analog slice would have the exact same form factor as a digital submodule, but would include a small ARM processor (to be defined), and a pair of 8-channel digital-to-analog converters responsible for converting 16 digital CV levels into analog signals. The 16-bit AD5360 could be used for this purpose. In order to support this configuration, the submodule interconnect on the backplane should include 2 analog audio pins, which would only be used by the analog slice, for the purpose of transporting the analog audio signal generated by the analog submodule. The retail price of the analog slice could be around $100, making analog submodules significantly more expensive than their digital counterparts, but easier to design as well, at least for anyone familiar with analog audio processing.
As mentioned earlier, the faceplate would provide 8 VC outputs. These outputs would be generated from a single AD5360 8-channel digital-to-analog converter. As a result, all matrixing and multiplexing would be done in the digital domain, removing the need for any AD75019 crosspoint switches — I really can’t believe that we would not use these after all…
8 stereophonic audio outputs would also be provided on the faceplate. But in order to reduce the use of real estate and facilitate the connection to audio interfaces like the Apogee Symphony I/O, these outputs should be exposed through a single DB25 connector.
The faceplate should also include two USB outputs, one connected to the Raspberry Pi 2, and the other connected to the matrixing component introduced below.
In keeping with our previous design, 16 dynamically-assigned rotary encoders would be mounted on the faceplate, and would be used to configure up to 16 settings per channel. These encoders would support RGB illumination and SPST momentary switching, allowing the direct selection of a channel.
While the most complex user interactions would be handled through a web-based graphical user interface served by the embedded Raspberry Pi 2 to a smartphone or tablet over a built-in WiFi hotspot, we would also provide a set of displays on the module’s faceplate. Following the awesome design of the Avid Pro Tools | S3, we could use multiple rows of 96 × 64 OLED displays, like the CFAL9664B-F-B1-CB RGB display. If doing so, controls and displays could be arranged in the following fashion on the faceplate:
- 1 row of 8 RGB illuminated knobs
- 1 row of 8 OLED displays
- 1 row of 8 RGB illuminated knobs
- 1 row of 16 jack chassis sockets for VC inputs
- 1 row of 8 OLED displays
- 1 row of 16 jack chassis sockets for VC outputs
With such an approach, the module could be used in a standalone fashion, without having to use any external device for the web user interface, nor any control surface. The only drawback, when compared to a traditional Eurorack module, would be the use of limited-resolution endless encoders, instead of regular potentiometers. Nevertheless, this seems to be the price to pay if one wants stateful settings.
Matrixing & Multiplexing
Then comes the issues of matrixing and multiplexing all these digital signals. For that rather critical part, the thinking goes that a small FPGA (144 pins, 50k gates) or an XMOS device could be the way to go. Of course, this would make the complexity of our system go through the roof, but it would offload the Raspberry Pi 2 from a lot of tasks that it was never designed to handle. Clearly, this is an area that I am not familiar with, and a lot more research will have to go into this before we can commit to any design.
This design is clearly better than anything we’ve come up so far. I wish I could claim credit for it, but I really can’t. Instead, I was just the instigator of a fabulous brainstorming effort between an expert and a total newbie. The expert in question believes that we’re looking at a 3 to 4 person-year effort. I really can’t challenge his experience and judgement, which leads me to believe that we won’t have a working prototype anytime soon. But now that I have a solid outline to work from, I really cannot go back to something simpler. Therefore, I will give it my very best shot.
Wish me luck, for I will need it…
And if you want to give me a hand, ping me!