[request] midi clock to BPM

[osuarez]

Is there a chance to utilize midi clock as a way to determine bpm?

[support]

Noted.
We will check this, after first V8 stable will be released.

[osuarez]

Hello again, I thought I would bring this subject up again and see if there is any opportunity of getting midi clock added into software to use as a method of getting BPM?

[support]

Please give more specifications (including the midi messages to take care of).

[Earl Harvey]

The MIDI time code is 32 bits long, of which 24 are used, while 8 bits are unused and always zero. Because the full-time code messages requires that the most significant bits of each byte are zero (valid MIDI data bytes), there are really only 28 available bits and 4 spare bits.

Like most audiovisual timecodes such as SMPTE time code, it encodes only time of day, repeating each 24 hours. Time is given in units of hours, minutes, seconds, and frames. There may be 24, 25, or 30 frames per second.

Each component is assigned one byte:

Byte 0
0rrhhhhh: Rate (0–3) and hour (0–23).
rr = 00: 24 frames/s
rr = 01: 25 frames/s
rr = 10: 29.97 frames/s (SMPTE drop-frame timecode)
rr = 11: 30 frames/s
Byte 1
00mmmmmm: Minute (0–59)
Byte 2
00ssssss: Second (0–59)
Byte 3
000fffff: Frame (0–29, or less at lower frame rates)
Full time code[edit]
When there is a jump in the time code, a single full-time code is sent to synchronize attached equipment. This takes the form of a special global system exclusive message:

F0 7F 7F 01 01 hh mm ss ff F7
The manufacturer ID of 7F indicates a real-time universal message, the channel of 7F indicates it is a global broadcast. The following ID of 01 identifies this is a time code type message, and the second 01 indicates it is a full-time code message. The 4 bytes of time code follow. Although MIDI is generally little-endian, the 4 time code bytes follow in big-endian order, followed by a F7 "end of exclusive" byte.

After a jump, the time clock stops until the first following quarter-frame message is received.

Quarter-frame messages[edit]
When the time is running continuously, the 32-bit time code is broken into 8 4-bit pieces, and one piece is transmitted each quarter frame. I.e. 96—120 times per second, depending on the frame rate. A quarter-frame messages consists of a status byte of 0xF1, followed by a single 7-bit data value: 3 bits to identify the piece, and 4 bits of partial time code. When time is running forward, the piece numbers increment from 0–7; with the time that piece 0 is transmitted is the coded instant, and the remaining pieces are transmitted later.

If the MIDI data stream is being rewound, the time codes count backward. Again, piece 0 is transmitted at the coded moment.

The time code is divided little-endian as follows:

MIDI time code pieces
Piece # Data byte Significance
0 0000?ffff Frame number lsbits
1 0001?000f Frame number msbit
2 0010?ssss Second lsbits
3 0011?00ss Second msbits
4 0100?mmmm Minute lsbits
5 0101?00mm Minute msbits
6 0110?hhhh Hour lsbits
7 0111?0rrh Rate and hour msbit

[Earl Harvey]

Giving SX the ability sync and/or transmit MTC would be a welcome !

[support]

Thank you for this explanation.

So what you call "Midi clock" is finally MTC (Midi Time Code) ?
Or is there existing two different protocols (Midi Clock and MTC) ?

[Earl Harvey]

Two Protocols... One is more for controlling transport

consider SMPTE as another protocol too if ever added...

[support]

Noted.
We are presently not interested with MTC (we already worked with it in the past, and it was a bad experience).
We would prefer a lighter protocole.
So we are still looking for more details about "Midi Clock".

[Earl Harvey]

I may be wrong considering them "two" protocols ... checking into more about it... Thanks!