Whats the best way to achieve this? In my patch the ticks are * by 24 to get the beat interval to feed to the metro...Of course this increases the range of the jitter by a factor of 24. Is there a way to cancel out this?

I've read up about the -sleepgrain flag also...does this really help? TO be honest its all a bit of a hack. Is there a way to optimize Pd for this. I find it a little difficult to get it into my head that in this day and age Pd does not have more sophisticated methods to syncing up to other apps and hardware...esp with midi sync. Or does nobdy else have these requirements!? :-/

(ps. Im on OSX and [midirealtimein] appears to be working even though it says only MSW. Is this the same for Linux?)

http://www.pdpatchrepo.info/hurleur/midi_clock_in.pd

Just guessing, maybe the midi timing errors are about buffering/latency in the OS rather than inside Pd. Are all your other MIDI apps playing nice with the same clock source?

-sleepgrain is for the audio DSP, so I don't think it will help a lot with MIDI timing.

How is everyone else getting along with MIDI clock and so forth? (I don't really use it)

I think becasue the events aren't timestamped they are only getting through, not necessarily locked to any grid. This might work if the events can be quantized to a grid somehow?

I keep coming back to needing this functionality so it would be good if I could find a solution...

I read this in the html help for Pd:

MIDI and sleepgrain

In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."

The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.

Sounds like sleepgrain should be set low then. Another possibility is to question the accuracy of [alternate] and [timer]. Are you sure that what is arriving at [midirealtimein] is skewed?
(I'm trying to think of a test you can do that doesn't use timer

Exactly - I have no idea!! Only that i could tap 'whatever' is coming out of it and time the intervals.

THere seem to be a lot of half finished syncing objects in Pd. I mean, where are these: http://lists.puredata.info/pipermail/pd-list/2004-03/018197.html

Agreed, it's not a very satisfactory situation. Perhaps post a message on list and nicely ask what the current state of play is. Maybe one of the midi object devs will pop up and say which objects are working and where to find them
a.

Yep I think ur right. I'll report back any findings. This would be massively useful....to me anyway

Thanks again.

Ok I got some feedback.

A kind person on the list posted a patch which is attached if anyone finds it useful...maybe it should go in the patches section.

However, for me, I'm pretty sure that on this kit the jitter is going to be too much of a problem, so the best I can do for now is wait until Jack gets its Midi activated. Its pretty much there I'm sure of it judging by the reply i got from one of the JAck developers.

For those Linux users using PD and JAck. Does the JackTransport work well for Pd? I mean how do you folk sync up Pd and say Hydrogen/Ardour?

best, S

http://www.pdpatchrepo.info/hurleur/midi_sync.pd