On 27 May 2012 09:17, Sean M. Pappalardo - D.J. Pegasus <
spappala...@mixxx.org> wrote:
> I started thinking of how to implement this while creating that, and we're
> going to have a problem with clock drift because we don't currently have a
> timing source with microsecond precision. (Since there are 24 clock pulses
> per beat, 120BPM is a clock pulse every 20833us, 150BPM is every 16667us
> and so on.) QTimers only have millisecond precision and may fire late. So
> even if they were on time, they could only accurately represent 78.125BPM
> (32ms), 100BPM (25ms), 125BPM (20ms), 156.25BPM (16ms), 250BPM (10ms), etc.
> Other whole ms values translate to fractional BPM values. (If you want to
> make your own spreadsheet, the formula is (1/(<timer value in
> ms>/1000))/24*60 )
>
> On top of this, even the beat_active CO (which we would sync to on each
> beat) is only accurate to 50ms according to the Wiki.
>
i don't *think* this is a big issue, it would just have to vary the number
of full ms between each tick it sends out. effectively adding jitter to get
to the right bpm. apps have to be sensible in how they process incoming
midi clock and take an average anyway. *how* cunning they are varies of
course:
* clock from traktor on mac is fairly stable but not without jitter and
ableton isn't very good at synching to it
* ableton's clock is probably about as stable as traktors but traktor has
no problems synching to the clock from ableton
* my own midimasher implementation can lock onto traktor's clock without
any issues, it uses quite a large sample of clock ticks (192 for 8 beats
worth) to smooth out the jitter
users on windows will have the extra jitter added by having to use virtual
midi ports too - clock will always more more stable and usable on mac or
linux than windows
i'll hack some code into mixxx just to experiment and compare the clocks
stability to traktor and ableton. since most (all?) apps won't have higher
than 1ms accuracy when decoding midi clock they have no choice but to
average out over a number of clock ticks to find the real bpm anyway. you
certainly can't just assume that the delay between any two is an accurate
1/24th of a beat.
we would also need a 'send clock' button that would send out a clock
'start' message on the next quantized beat or something. sync will drift
when changing tempo a bit so users will need to click on that manually
every now and again or possibly mixxx could just send out a start (0xfa)
message every X sets of 8 beats? tho the 50ms accuracy you mention for the
beat_active CO would be an issue. the start message really needs close to
frame level accuracy i guess.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
