Midi beat clock is sent at 24 pulses per quarter note: https://en.m.wikipedia.org/wiki/MIDI_beat_clock Can anyone recommend an algorithm suitable for tempo estimation/clock recovery (in case of clock loss) and hopefully can rapidly adapt to changing incoming clock rates? Thats within the capabilites of an 8 bit uC? -- ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
Midi Beat Clock
Started by ●January 28, 2016
Reply by ●January 28, 20162016-01-28
On Thu, 28 Jan 2016 13:53:36 -0500 (EST), bitrex <bitrex@de.lete.earthlink.net> wrote:> >Midi beat clock is sent at 24 pulses per quarter note: > >https://en.m.wikipedia.org/wiki/MIDI_beat_clock > >Can anyone recommend an algorithm suitable for tempo > estimation/clock recovery (in case of clock loss) and hopefully > can rapidly adapt to changing incoming clock rates? > >Thats within the capabilites of an 8 bit uC? >Sounds like a good application for a digital phase locked loop, no? Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 28, 20162016-01-28
eric.jacobsen@ieee.org (Eric Jacobsen) Wrote in message:> On Thu, 28 Jan 2016 13:53:36 -0500 (EST), bitrex > <bitrex@de.lete.earthlink.net> wrote: > >> >>Midi beat clock is sent at 24 pulses per quarter note: >> >>https://en.m.wikipedia.org/wiki/MIDI_beat_clock >> >>Can anyone recommend an algorithm suitable for tempo >> estimation/clock recovery (in case of clock loss) and hopefully >> can rapidly adapt to changing incoming clock rates? >> >>Thats within the capabilites of an 8 bit uC? >> > > Sounds like a good application for a digital phase locked loop, no? > > > Eric Jacobsen > Anchor Hill Communications > http://www.anchorhill.com >I thought digital phase locked loops were difficult to implement well at low frequencies. But I'm no DSP expert, obviously... -- ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
Reply by ●January 28, 20162016-01-28
On Thu, 28 Jan 2016 15:58:44 -0500 (EST), bitrex <bitrex@de.lete.earthlink.net> wrote:>eric.jacobsen@ieee.org (Eric Jacobsen) Wrote in message: >> On Thu, 28 Jan 2016 13:53:36 -0500 (EST), bitrex >> <bitrex@de.lete.earthlink.net> wrote: >> >>> >>>Midi beat clock is sent at 24 pulses per quarter note: >>> >>>https://en.m.wikipedia.org/wiki/MIDI_beat_clock >>> >>>Can anyone recommend an algorithm suitable for tempo >>> estimation/clock recovery (in case of clock loss) and hopefully >>> can rapidly adapt to changing incoming clock rates? >>> >>>Thats within the capabilites of an 8 bit uC? >>> >> >> Sounds like a good application for a digital phase locked loop, no? >> >> >> Eric Jacobsen >> Anchor Hill Communications >> http://www.anchorhill.com >> > >I thought digital phase locked loops were difficult to implement > well at low frequencies. But I'm no DSP expert, obviously...For a simple example case, at 120bpm, 24 clocks per beat (quarter note), that's a 48Hz clock that you're trying to track/replicate. That is kind of slow, but certainly doable, and whether it is a good solution or not will likely depend on the details of other contraints, like acuisition time, drift tolerence, and how "rapid" is the "rapidly adapt to changing incoming clock rates." A DPLL, once it has acquired the beat clock, will do a good job of sustaining the clock for the case of loss of input clock. How well it can hold the rate and how well it will adapt to changing rates depends on the implementation, but none of it is super-difficult for someone familiar with DPLLs. I'm sure there are other methods, but it seems like an obvious application where a DPLL would be considered. "Low frequency" is relative to the outside world, not to the DPLL, since once everything is digitized it's all relative to fs = 1.0, anyway. ;) Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 28, 20162016-01-28
On 28.01.2016 23:58, bitrex wrote: > > I thought digital phase locked loops were difficult to implement > well at low frequencies. But I'm no DSP expert, obviously... > Difficulties with a DPLL may arise at high, not low frequencies. A convenient quote from Gardner's "Phaselock Techniques" (3rd ed., p. 85): "Engineering folklore holds that behavior of a time-descrete system is close to that of a time-continuous system if the bandwidth (however 'bandwidth' may be defined) of the time-discrete system is small compared to the sampling rate." I would suggest that you might need a second-order DPLL. Be careful that you might need more than 8 bits to accurately represent frequency within a DPLL integrator. But you totally can implement e.g. 16 bit arithmetic in a 8-bit microcontroller. Regards, Evgeny.
Reply by ●January 28, 20162016-01-28
Evgeny Filatov <filatov.ev@mipt.ru> Wrote in message:> On 28.01.2016 23:58, bitrex wrote: > > > > I thought digital phase locked loops were difficult to implement > > well at low frequencies. But I'm no DSP expert, obviously... > > > > Difficulties with a DPLL may arise at high, not low frequencies. > > A convenient quote from Gardner's "Phaselock Techniques" (3rd ed., p. > 85): "Engineering folklore holds that behavior of a time-descrete system > is close to that of a time-continuous system if the bandwidth (however > 'bandwidth' may be defined) of the time-discrete system is small > compared to the sampling rate."Awesome. My idea to phase lock to the rise and fall of tides in the Nile should work great, then...;)> I would suggest that you might need a second-order DPLL. Be careful that > you might need more than 8 bits to accurately represent frequency within > a DPLL integrator. But you totally can implement e.g. 16 bit arithmetic > in a 8-bit microcontroller. > > Regards, > Evgeny. >Thank you, I will do more research on that one! -- ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
Reply by ●January 29, 20162016-01-29
On Thu, 28 Jan 2016 13:53:36 -0500, bitrex wrote:> Midi beat clock is sent at 24 pulses per quarter note: > > https://en.m.wikipedia.org/wiki/MIDI_beat_clock > > Can anyone recommend an algorithm suitable for tempo > estimation/clock recovery (in case of clock loss) and hopefully can > rapidly adapt to changing incoming clock rates? > > Thats within the capabilites of an 8 bit uC?This sounds like a huge snarly ball of trouble, unless the MIDI beat clock messages are serialized, or some other message broadcasts the tempo. Your basic challenge comes from wanting to recover the clock in case of loss at the same time you're rapidly adapting to changing incoming clock rates. The reason it's a challenge is because it takes time to distinguish between a missed beat and a sudden drop in the tempo by a factor of two; without some additional information to tell you that you lost a message you can't accurately follow a sudden reduction in tempo at the same time that you're armed to accurately regenerate a missed beat clock message. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●January 29, 20162016-01-29
On Thu, 28 Jan 2016 15:58:44 -0500, bitrex wrote:> eric.jacobsen@ieee.org (Eric Jacobsen) Wrote in message: >> On Thu, 28 Jan 2016 13:53:36 -0500 (EST), bitrex >> <bitrex@de.lete.earthlink.net> wrote: >> >> >>>Midi beat clock is sent at 24 pulses per quarter note: >>> >>>https://en.m.wikipedia.org/wiki/MIDI_beat_clock >>> >>>Can anyone recommend an algorithm suitable for tempo >>> estimation/clock recovery (in case of clock loss) and hopefully can >>> rapidly adapt to changing incoming clock rates? >>> >>>Thats within the capabilites of an 8 bit uC? >>> >>> >> Sounds like a good application for a digital phase locked loop, no? >> >> >> Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com >> >> > I thought digital phase locked loops were difficult to implement > well at low frequencies. But I'm no DSP expert, obviously...Analog phase locked loops are difficult to implement at low frequencies because it's hard to find good capacitors to store the states for long periods of time. As long as the loop bandwidth is small compared to the repetition rate of the reference, digital phase locked loops are easy at low speeds. But that runs contrary to rapidly adjusting to changes in tempo. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●January 29, 20162016-01-29
On 30.01.2016 0:39, Tim Wescott wrote:> On Thu, 28 Jan 2016 13:53:36 -0500, bitrex wrote: > >> Midi beat clock is sent at 24 pulses per quarter note: >> >> https://en.m.wikipedia.org/wiki/MIDI_beat_clock >> >> Can anyone recommend an algorithm suitable for tempo >> estimation/clock recovery (in case of clock loss) and hopefully can >> rapidly adapt to changing incoming clock rates? >> >> Thats within the capabilites of an 8 bit uC? > > This sounds like a huge snarly ball of trouble, unless the MIDI beat > clock messages are serialized, or some other message broadcasts the tempo. > > Your basic challenge comes from wanting to recover the clock in case of > loss at the same time you're rapidly adapting to changing incoming clock > rates. The reason it's a challenge is because it takes time to > distinguish between a missed beat and a sudden drop in the tempo by a > factor of two; without some additional information to tell you that you > lost a message you can't accurately follow a sudden reduction in tempo at > the same time that you're armed to accurately regenerate a missed beat > clock message. >Wow, I've never guessed music is SO interesting! Indeed, I'm afraid that you can only go after one of the two aforementioned options. If there are missed beats and no sudden changes in the tempo, a conventional PLL would do well (e.g. you can update the loop filter once per an incoming beat, so a missed beat goes unnoticed). If there are sudden changes in the tempo while missed beats are rare, a possible solution would be to use a FLL + PLL combination. I.e. a loop with a filter which combines those of a first-order FLL and a second-order PLL (with a single NCO). Phase error could be extracted from differences between incoming and regenerated beats, while frequency error could be calculated as the difference between the frequency stored in the integrator and the frequency estimated as the reverse of the time interval between two succeeding beats. Regards, Evgeny.
Reply by ●January 30, 20162016-01-30
On Sat, 30 Jan 2016 03:05:14 +0300, Evgeny Filatov <filatov.ev@mipt.ru> wrote:>On 30.01.2016 0:39, Tim Wescott wrote: >> On Thu, 28 Jan 2016 13:53:36 -0500, bitrex wrote: >> >>> Midi beat clock is sent at 24 pulses per quarter note: >>> >>> https://en.m.wikipedia.org/wiki/MIDI_beat_clock >>> >>> Can anyone recommend an algorithm suitable for tempo >>> estimation/clock recovery (in case of clock loss) and hopefully can >>> rapidly adapt to changing incoming clock rates? >>> >>> Thats within the capabilites of an 8 bit uC? >> >> This sounds like a huge snarly ball of trouble, unless the MIDI beat >> clock messages are serialized, or some other message broadcasts the tempo. >> >> Your basic challenge comes from wanting to recover the clock in case of >> loss at the same time you're rapidly adapting to changing incoming clock >> rates. The reason it's a challenge is because it takes time to >> distinguish between a missed beat and a sudden drop in the tempo by a >> factor of two; without some additional information to tell you that you >> lost a message you can't accurately follow a sudden reduction in tempo at >> the same time that you're armed to accurately regenerate a missed beat >> clock message. >> > >Wow, I've never guessed music is SO interesting! > >Indeed, I'm afraid that you can only go after one of the two >aforementioned options. If there are missed beats and no sudden changes >in the tempo, a conventional PLL would do well (e.g. you can update the >loop filter once per an incoming beat, so a missed beat goes unnoticed). > >If there are sudden changes in the tempo while missed beats are rare, a >possible solution would be to use a FLL + PLL combination. I.e. a loop >with a filter which combines those of a first-order FLL and a >second-order PLL (with a single NCO). Phase error could be extracted >from differences between incoming and regenerated beats, while frequency >error could be calculated as the difference between the frequency stored >in the integrator and the frequency estimated as the reverse of the time >interval between two succeeding beats. > >Regards, >Evgeny. >It gets back to the requirements. How fast does the system have to adapt to a change in beat frequency (and it obviously can't be instantaneously, so it should be a definable time)? What is the allowable acquisition time for the loop to lock to the beat message when it's there (even if it's intermittent)? In other words, once the normal specs for a DPLL-ish system are determined, then the tradeoffs can be fully sorted out to know whether a DPLL with some adaptive features will work or whether the addition of an FLL makes sense or whether other approaches beckon. This might still be do-able with a DPLL with some adaptive features (e.g., switchable or adaptable BW, etc., etc.), but naturally it depends on the details of the requirements. And, yeah, the more it needs to react quickly to a change in frequency the more jitter it will have when trying to maintain a dropping clock, UNLESS there are other cues or information it can use to adapt. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
