[sdiy] Bus for digital patching of synths

Maarten Halmans diy at artefacts.nl
Fri Nov 8 12:13:47 CET 2013


Hello all,

AD & DA converters work with I2S,  why not create a I2S multiplexer in an 
FPGA? Add a Can or some similar bus to do communication between local 
microcontrollers on the modules and the main patching module.

Cheers,
Maarten

----- Original Message ----- 
From: "cheater00 ." <cheater00 at gmail.com>
To: "synth-diy" <synth-diy at dropmix.xs4all.nl>
Sent: Friday, November 08, 2013 11:42 AM
Subject: [sdiy] Bus for digital patching of synths


> Hi all,
> I've recently been talking with someone about an idea for patching
> modular synths in digital rather in analog.
>
> Let me restate the problem. We have an analog modular. It uses a lot
> of patch cables, which can get difficult to manage, and becomes even
> worse in consideration of polyphonic modulars. Instead, put an ADC on
> each output and a DAC on each input and connect them with the right
> bus. As a nearly free bonus you get patch storage. The question is
> what bus is right.
>
> My first thought was CAN. I've just had a closer look into CAN. Some
> people say can is only good up to 1 Mb/s, some say it depends on the
> uC. However, perhaps the format of can itself isn't optimal. Here's
> what a frame looks like:
>
> http://en.wikipedia.org/wiki/File:CAN-Bus-frame_in_base_format_without_stuffbits.png
>
> the "data" part can be longer, but still that's a bit of overhead.
>
> So far I've identified that ideal bus would have the following features:
>
> 1. it is shared. That is, multiple devices share the same medium.
> 2. it's oriented towards setting up constant streams of data between
> any two endpoints and having them active for a long time
> 3. shares bandwidth via TDM
> 4. after setup, the data should be sent bare, other than infrequent
> housekeeping frames. This means once your link is established you
> should be able to take a byte from the DAC and output it to the bus
> directly.
> 5. only needs to be very local, say 2-4 meters
> 6. it is switched. This way the collision domains are made smaller and
> network bandwidth utilized much more efficiently. So you could group
> your modular into domains of 10 modules and have a fabric connecting
> them.
> 7. needs fairly high speeds (~50-100 megabits/sec). This means on a
> single collision domain, there could be 10 monophonic modules which
> each have 6 inputs or outputs at 100 kHz at 20 bits (this is a rough
> estimate so far). With a fully switched network with a 1 Gb/s backbone
> you can realize an 8-voice or even 16-voice modular, or just use
> separate networks for each voice. I have a feeling using a single
> high-bandwidth network will however mean much simpler synchronization,
> whereas in disparate networks the frames, link times, etc might not
> line up and so some voices will receive sound later, making for
> unpredictability in edge cases - voices would sound different at
> extreme settings.
> 8. it does not do any CRC or delivery assurance. To minimize delay
> there is no time for this overhead.
> 9. needs to have hardware support in a variety of microcontrollers
>
> So far I feel like I'm mostly describing copper Ethernet, unless
> someone can point me to something different/better.
>
> Here are the features of Ethernet which aren't exactly necessary:
> 1. You don't need this to work over 100 meters or run over UTP.
> However, being able to patch together fairly distant modulars (like in
> another studio) could be a door opener for many things. Optical links
> could take care of the ground potential issue over long distances.
> 2. You don't need galvanic isolation. However, magnetics are cheap,
> and you might find them good to have: digital mess is decoupled from
> your module, it lessens the chance of incompatibility between devices,
> no need to meticulously carry differential lines over connectors and
> larger distances, etc. Think of MIDI optocouplers. With very
> inexpensive switches being built by the billion, you can surely find
> something down at double cents. Just don't go to Element 14 ("Formerly
> Farnell")
> 3. You don't need the ethernet frame and everything it brings with
> itself. For one thing it's a huge amount of overhead unless you buffer
> the data, which then means delay.
>
> The last point is a fairly big issue. Maybe there are some tricks with
> Ethernet to make it transport data in a TDM fashion. Maybe that makes
> the standard unsuited.
>
> This question is relevant for the more complicated polysynths as well.
> If you were making a new CS80, and wanted it to be highly
> configurable, you might want to consider digital patching. For lower
> requirements, like simple monosynths, a lower-end, more localized bus
> such as CAN might be advantageous, that is if digital patching is
> required at all.
>
> D.
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy 




More information about the Synth-diy mailing list