MIDI beat/tempo clock output
Have Mixxx emit a MIDI clock signal on selected MIDI devices so external programs and devices can sync with Mixxx's deck(s).
Blueprint information
- Status:
- Not started
- Approver:
- Mixxx Development Team
- Priority:
- Low
- Drafter:
- Sean M. Pappalardo
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Related branches
Sprints
Whiteboard
This is going to be subject to 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.
So the question is: would the MIDI clock signal be useable given this level of inaccuracy?
If not, there is the MIDI Tick message that fires every 10ms, but do all devices support it?
Timer alternatives:
1.
We may use the fork of the Qt internal performance timer like used in
http://
It has a ns resolution from its data type. The actual resolution in terms of step wide varies from the underlying implementation. Depends somehow on the main CPU Cristal
2.
We may use the DAC timer from the sound card provided by PortAudio Pa_GetStreamTime. Depends somehow on the Sound card Cristal
http://
Note: Both sound sources may show a significant drift to each other and compared to the wall clock based QTimers.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
