[sdiy] Bus for digital patching of synths

[Neil Johnson]

Hi,

1/ Converters need to be DC to, say, 40kHz.  DC specs need to exceed
that needed for handling pitch CVs. Audio specs don't need to be that
good as synth circuits generally not designed to the same quality as
in high-end recording gear (how many bits do you need to capture the
output of a TL072?).

2/ Have you considered CopperLAN?

3/ Latency between modules, especially handling gate and trigger signals:

http://www.innerclocksystems.com/New%20ICS%20Litmus.html

4/ Cost - where is the breakeven point?

http://www.gearslutz.com/board/so-much-gear-so-little-time/867829-chat-about-future-digitally-controlled-analog-console.html
http://www.muffwiggler.com/forum/viewtopic.php?t=68864

Granted, you're only suggesting replacing the patch cables with
ADC->cable->DAC so no need to worry about converting pots and switches
into something digitally controllable.  But then you've split the UI
into a panel of knobs, and an application running on a computer that
manages the interconnections.  Or were you thinking of adding some
sort of interactive button pressing/touchpads/etc scheme to set up
virtual patch cords?

In the meantime write up the specs so that manufacturers can implement
the functionality in their modules, arrange plugfests so that
manufacturers can get together and debug the interactions between
their modules, and so on.  Read up about CopperLAN and the approach
they've taken (technically and businesswise).

And convince the (small) market that your solution, while not pure
analogue end-to-end modular synth, is just as good if not better,
definitely better than a fully software environment (e.g. Reaktor).

Sounds like fun!

Neil
(PS: ADC on INPUT and DAC on OUTPUT)


On 8 November 2013 10:42, cheater00 . <cheater00 at gmail.com> wrote:
> 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



-- 
--
http://www.njohnson.co.uk