Yahoo Groups archive

Doepfer

Index last updated: 2026-04-29 00:15 UTC

Thread

Distributing a clock

Distributing a clock

2017-04-05 by Tim Burgess

Hi,

My modular is currently spread across 2 frames (an LC9 and a G6) that have a couple of meters gap between them. I intend to get a single large frame when I can afford it but, in the meantime, I need to figure out the best way to distribute clock signals between the frames. Currently, I’m using passive mults to distribute clocks within each frame, with a suitable long cable joining a mult on one frame to a mult on another. I’ve used the best quality cable I could get, as I appreciate losses happening over long connections and I don’t seem to be having any issues at the moment, but would I be better using buffered mults for handling clocks?

Best wishes.

Tim Burgess

AW: [Doepfer_a100] Distributing a clock

2017-04-05 by yahoo@doepfer.de

> Hi,
>
> My modular is currently spread across 2 frames (an LC9 and a G6)
> that have a couple of meters gap between them. I intend to get a
> single large frame when I can afford it but, in the meantime, I
> need to figure out the best way to distribute clock signals
> between the frames. Currently, I’m using passive mults to
> distribute clocks within each frame, with a suitable long cable
> joining a mult on one frame to a mult on another. I’ve used the
> best quality cable I could get, as I appreciate losses happening
> over long connections and I don’t seem to be having any issues at
> the moment, but would I be better using buffered mults for
> handling clocks?
>
> Best wishes.
>
> Tim Burgess

After all It depends upon the output of the clock transmitter and the inputs
of the clock receivers (levels, impedance/load). I never discovered any
problem with clock signals generated e.g. by one of our midi interfaces or
an LFO as clock source, even over longer distances (e.g. three cables
A-100C200 connected via passive multiples) and more than only one receiver.
But it's  certainly not a bad idea to use buffered multiples to be on the
safe side.

Best wishes
Dieter Doepfer

P.S. We will show a multicore module at the Superbooth in Berlin that can be
used to connect up to 12 control signals with one standard multiwire cable
between two cases. It has been suggested by several customers who play live
on stage with two or more cases as it simplifies the pre-patching.

Re: [Doepfer_a100] Distributing a clock

2017-04-05 by Florian Anwander

I have never experienced problems with "analogue" clock transfering over 
wide distances. I use 5 and 10 m cables all the day in my studio with 
passive multiples.

I remember having a 30 meter asymmetric cable feeding clock from an 808 
on stage to a Boss DE-200 delay in the rack at the front-of-house mixer. 
It worked like charm.

RE: [Doepfer_a100] Distributing a clock

2017-04-07 by Tim Burgess

Dieter,

Many thanks for the reassurance. I'm relatively new to modular and I asked
the question to improve my understanding as much as anything else. I was
concerned that losses in the cable might cause smearing of the clock pulse
shape that might lead to less robust triggering. I'll add some buffered
mults to my shopping list, but maybe as a lower priority.

Best wishes.

Tim Burgess
Show quoted textHide quoted text
-----Original Message-----
From: Doepfer_a100@yahoogroups.com [mailto:Doepfer_a100@yahoogroups.com] 
Sent: Wednesday, April 5, 2017 3:48 PM
To: Doepfer_a100@yahoogroups.com
Subject: AW: [Doepfer_a100] Distributing a clock

> Hi,
>
> My modular is currently spread across 2 frames (an LC9 and a G6) that 
> have a couple of meters gap between them. I intend to get a single 
> large frame when I can afford it but, in the meantime, I need to 
> figure out the best way to distribute clock signals between the 
> frames. Currently, I'm using passive mults to distribute clocks within 
> each frame, with a suitable long cable joining a mult on one frame to 
> a mult on another. I've used the best quality cable I could get, as I 
> appreciate losses happening over long connections and I don't seem to 
> be having any issues at the moment, but would I be better using 
> buffered mults for handling clocks?
>
> Best wishes.
>
> Tim Burgess

After all It depends upon the output of the clock transmitter and the inputs
of the clock receivers (levels, impedance/load). I never discovered any
problem with clock signals generated e.g. by one of our midi interfaces or
an LFO as clock source, even over longer distances (e.g. three cables
A-100C200 connected via passive multiples) and more than only one receiver.
But it's  certainly not a bad idea to use buffered multiples to be on the
safe side.

Best wishes
Dieter Doepfer

P.S. We will show a multicore module at the Superbooth in Berlin that can be
used to connect up to 12 control signals with one standard multiwire cable
between two cases. It has been suggested by several customers who play live
on stage with two or more cases as it simplifies the pre-patching.



------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

RE: [Doepfer_a100] Distributing a clock

2017-04-07 by Tim Burgess

Wow, that really puts my question into perspective. Thanks for sharing.

Best wishes.

Tim Burgess
Show quoted textHide quoted text
-----Original Message-----
From: Doepfer_a100@yahoogroups.com [mailto:Doepfer_a100@yahoogroups.com] 
Sent: Wednesday, April 5, 2017 4:10 PM
To: Doepfer_a100@yahoogroups.com
Subject: Re: [Doepfer_a100] Distributing a clock

I have never experienced problems with "analogue" clock transfering over
wide distances. I use 5 and 10 m cables all the day in my studio with
passive multiples.

I remember having a 30 meter asymmetric cable feeding clock from an 808 on
stage to a Boss DE-200 delay in the rack at the front-of-house mixer. 
It worked like charm.



------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.