2017-02-14 18:35 GMT-02:00 Dan Wilcox <danomatika@gmail.com>:
I’m looking to add a function to libpd for the new [midiclkin] object.

it's not quite "new", seems to have been there maybe forever, just found it in pd-0.35-0...

but it didn't have a help file and it wasn't working...

anyway, I filed a bug report for it in vanilla, and thought I could bring it to purr data as well and they figured it out over there 

https://git.purrdata.net/jwilkes/purr-data/issues/255

check this particular message:

MIDI clock is one of the system realtime messages. It's used for tempo sync between MIDI clients. The master sends 24 clocks per quarter note, so that the slave knows what the current tempo is. http://midi.teragonaudio.com/tech/midispec/clock.htm

So we have midiin for all kinds of raw MIDI data (MIDI status and data bytes) as they come in, and two convenience objects, midirealtimein which only spits out the MIDI status bytes which happen to be system realtime messages (clock, start, stop, etc.), and midiclkin which specifically deals with the MIDI clock messages. This makes perfect sense.

The 1 bit every 3 pulses obviously counts off the 32th pulses (the clocks themselves are 1/3 of that, i.e. 64th triplets), so that seems sensible as well.

AFAICT, the implementations of midirealtimein and midiclkin are exactly analogous, except that the latter does some internal calculations to detect pulses and the current tempo (actually the corresponding time delta between clocks) instead of just outputting the status byte.

There's a small glitch in midiclkin_list() where the variable names seem to indicate that the left outlet is a "value" and the right outlet a "count", which obviously isn't true, but that's just the naming of the variables there (probably an editing blunder) and in any case doesn't affect the functioning of the object in any way.

So all in all the code looks good to me, it's just that it apparently never gets triggered anywhere. I'm not sure where that's supposed to happen, I'd have to dig into the MIDI back-end code to say more, but I'm not in the mood right now. I don't think that it's a big thing, probably just a missing send to the #midiclkin receiver somewhere. Miller should probably be able to have that fixed in no time at all. ;-)

Can't we just leave this to Miller and then backport his fix? :)

FWIW, here's my own test patch: midi-clocks.pd "