I’m looking to add a function to libpd for the new [midiclkin] object.
What is the timing timing argument in:
void inmidi_clk(double timing)
Is that for latency compensation?
Also, I noticed the function declaration is not present in s_stuff.h...
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 https://git.purrdata.net/jwilkes/purr-data/uploads/d0af4198bc841d037e91fca29d8babf0/midi-clocks.pd "
2017-02-14 21:38 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
"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."
Ok, I get this now, it's 24 clock ticks pert quarter note, so 12 is eight notes, 6 ticks is 16th and 3 ticks is 32th notes. 1 tick is then 64th tuplets
So, the left output sends a 1 at every 3rd tick, which is a way to trigger on 32th notes and filter out the 64th tuplets, cool...
problem is, the "1" comes at every 3rd tick... so it's not in sync at the head of the tempo, it is off by two 64th tuplets.
it would make much more sense to me if the first tick is "1" and then the 2nd and 3rd tick are filtered out.
cheers
-
Alexandre Torres Porres -
Dan Wilcox