thanks for the encouragement.
So I’ve changed my metro+transport patches to plugsync~, and it seems to work perfectly!

The attached example shows a synced 16th note counter.
Interestingly, plugsync~ delivers the current transport position also when not running.
So I’ve inserted a gate to avoid possible effects when the patch is loaded.

Any comments/improvements are welcome.

— Pasted Max Patch, click to expand. —

Copy all of the following text. Then, in Max, select New From Clipboard.

Hi. I’ve just found the plugsync~ object. Why isn’t it called live.plugsync~? Does it work outside the M4L context? If not, I don’t understand this naming convention. I’ve lost some valuable time trying to receive tempo related info inside M4L. I was trying to parse the midiin messages to receive the MIDI clock from the host, but this information isn’t sent by MIDI.

My suggestion for the naming would be to create some kind of alias, as you already do, for instance, with the zl object or the jit.op objects: you can use zl.x or zl x, jit.op @op + or jit.+.

My suggestion, in order to more easily discover M4L specific objects, would be to also name it live.x: Examples:
midiin or live.midiin (as it can be used inside M4L or outside).
plugout~ would be just live.plugout~, because it is not used in other contexts. plugsync~ would also just be live.plugsync~. Now of course, I understand that for retrocompatibility, the original naming would have to be held.

P.S: this is not nitpicking… ;-) It’s only a suggestion to more easily find objects in their particular context.