1. Home
  2. Electronics Design
  3. Syncing a digital oscillator to MIDI clock

Syncing a digital oscillator to MIDI clock

I'm working on a project where I'd like to sync a LFO implemented as a phase accumulator oscillator to incoming MIDI clock on the UART of a microcontroller. The current setup is using an ATMega168 with a series of 256 element lookup tables of 8 byte values that contain the bandwidth-limited LFO waveforms. A 24 bit phase accumulator is used and the top byte of the accumulator is used as an index into the wavetable; at the appropriate times the accumulator is incremented and the value stored at the wavetable index is output to the ATmega's PWM analog outputs after being linear interpolated. A 4 pole Bessel filter on the output filters the sampling frequency and the 64Khz PWM frequency.

This seems to work OK, but what I'd like to do now is sync the frequency of the LFO to incoming MIDI clock. This comes in on the UART as a data byte sent by the MIDI master device 24 times per quarter note. I'm looking for ideas on what might be the best approach to synchronize the LFO to the incoming clock? The LFO frequencies would be significantly lower than the incoming clock, with a maximum period of perhaps 16 seconds down to a quarter second depending upon the tempo and user settings. One straightforward idea I considered was to extract a rough tempo from the average time between the clock bytes as a running calculation, calculate the angle increment for the accumulator based on that, start the LFO going, and then keep count of how many clock ticks it takes for the LFO to complete a cycle. Compare that to how many clock ticks there actually should be in a cycle, and then nudge the angle increment up or down accordingly.

I have a feeling, however, that this will work like crap at the slow frequencies I have in mind. The lock doesn't need to be extremely tight, though, just "good enough for rock 'n roll." Would something like a phase locked loop work better in this application, even at these frequencies? I've never tried doing a PLL in software and am frankly pessimistic about my abilities as far as getting one working - I haven't done much DSP programming. I'm willing to give it a try, however, if that's the solution that's recommended. Thanks for any advice.

Reply to
Bitrex
Loading thread data ...

d

"Sound" like a reasonable approach. Are the UART data time stamped? I would hate to rely on the UART for timings. First thing is to determine how many timers/counters you need. I was looking at an apps needing at least two 16 bits timers, so the 8 bits and 16 bits timers of most AVR won't work. ARMs (Cortex M3) usually have 2 16 bits and 2

32 bits timers/counters. Faster A2D and better math libraries also helps. By the way, the major show stopper for my AVR is casting floating points into fixed points. It should work but it doesn't, even with the latest gcc based winavr. I have no choice but to ARM myself this time.

At low frequencies, hardware PLL is even more difficult.

That might drive you into ARM as well.

Reply to
linnix

If you can rely on the consistency of your internal clock then how bout just averaging the midi clock and use that average as your basis? Basically your "straightforward method" but just using an average. You can do without without a FIFO but a running average would probably be prefered. This would allow you also to seamlessly use the LFO without any midi clocks by initializing the average properly.

You can also do a little bit of statistical analysis such as throwing out outliers since you know approximately what the clock should be. By using a FIFO of a small size(say 10 to 100) then you won't have long term drift.

If this LFO is going to be used in a way that will be heard then you do not want to use a method that "instantaneously" locks on because it will be audible.

Reply to
BillyGates

I think you should work on the averaging idea because I don't believe you can depend on the MIDI date stream to be consistent.

Reply to
Jamie

series

and

wavetable;

the

frequency

data

the

significantly

rough

on

linnix, your issue about casting float to fixed point is in an interest=20 area of mine. Could we discuss it in another thread?

these

haven't

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.