From Colin f Sent Thu, Nov 27th 2003, 17:10
From Colin f Sent Thu, Nov 27th 2003, 17:10
> -----Original Message----- > Date: Thu, 27 Nov 2003 11:32:13 +1100 > To: xxxxxxxx@xxxxxxxxx.xxx > From: Robin Whittle <xx@xxxxxxx.xxx.xx> > Cc: xxxx@xxxxxxxx.xxx > Subject: Re: [AH] DIN Sync Splitter and DIN Sync timing gotchas > Unfortunately there's no technical specification on the > timing of Roland > (AKA DIN) Synch. As far as I know, there's no spec on the > minimum width > of the clock pulse, or even the voltages which must be used. The minimum clock pulse width is implied by the period of the interrupt oscillator in the 303, 606 and 808, which all share the same CPU (with different code, obviously). These CPUs are interrupted every 1.8ms, and it's during this interrupt that they poll the DIN sync inputs for pulses. The clock pulse must be long enough that it wont be missed by a process called every 1.8ms. Th sync convertors I build originally generated a 2ms pulse, to give the maximum possible tempo, without being too short. A large number of people have built these and used them with no problem, but I had a couple of reports of them not working with older devices, and also with 303s that had their internal trimmer for interrupt time 'tweaked', so I increased the pulse length to 4ms. A 4ms pulse, followed by a 4ms space, corresponds to a tempo of 312 bpm, which is certainly fast enough for me. The space has to be at least as long as the pulse, as the interrupted CPU has to see it, as well as the pulse. I've only had one report of a CR8000 not being able to sync properly to this, but it seems to want a true 50% square wave clock. To generate that, you need to keep track of the current tempo, and vary the din clock pulse length accordingly, which my P3 sequencer does. > This means > writing software in the device to count up potentially several MIDI > clock codes which might arrive faster than they can be sent out to the > Roland Synch device - and then catching up with them by sending Clock > pulses at some reasonable (whatever that means) rate, involving some > limit on how short the pulse can be, and how short the delay until the > next one. If the midi clock bytes arrive closer together than DIN sync can handle, then the instantaneous tempo is higher than the slaved device can possibly handle. I'd say that's a problem with the source, rather than the destination. Personally I think if a midi device is introducing that much error in it's clock output, it's not a stable enough clock. Colin f