[PD-dev] midiclkin

[Alexandre Torres Porres]

2017-02-14 18:35 GMT-02:00 Dan Wilcox <danomatika at 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
<https://git.purrdata.net/jwilkes/purr-data/uploads/d0af4198bc841d037e91fca29d8babf0/midi-clocks.pd>
 "
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20170214/d9e2e84d/attachment.html>