So, this one week total silence means that no one ever wanted to synchronize a Max transport object with something else? :)

I'm not sure if a MIDI beat clock receiver exists already somewhere but you could try to implement it yourself. The basics are quite simple.

From [rtin] you get the following bytes/numbers:

250 -> start 252 -> stop 248 -> tick

The sender delivers 24 ticks per beat. So you can measure the time interval T of arriving ticks using [timer] and calculate the BPM tempo from it.

BPM = 60000/(24*T), with T in milliseconds.

Here is a patch as proof of concept.

Yes, thank you! I actually tried this technique already, but i am not really satisfied with the timing. And this system will drift a lot. Not very groovy.. ;) Before the transport system i used to do everything with signal objects. Then it's easy to switch to a phasor~ coming from another computer via SPDIF. I guess this is still the only way if you want decent timing. Too bad because i think transport is really good if you don't have to sync it to something else though. It would be really nice with some more sync options for us who don't use Live or Rewire.

But is it possible to have the transport in a "passive" mode where you can drive it with the tick value only? I tried this, but since it seems impossible to set the tempo to 0, this conflicts with the incoming ticks. Or maybe i'm doing something wrong? I would like it to be started, but not running. Something like this:

I've been wondering for a while about slaving transport to an MSP master of some sort, your patch and question prompted this response:

not a whole lot of use as it is, but the idea is to let transport know what tempo we are at (in this patch it's more the other way round), and then let transport run on its own with just occasional updates from the phasor~ side (once per bar in this patch) - or something like that . . . this is just a quick sketch, and I'm not sure if it will ever be of any use to you, or me, or any one

this actually seems pretty decent here just trying with a trigged cycle~/line~ combo. probably better not to update snapshot~ too often. thanks! one question about your use of the delta~ before the

to get the bang at the start, not the middle, of the phase loop.

also, cudnylon (in https://cycling74.com/forums/master-transport-to-phasors-or-master-phasor-to-rates-for-global-clock ) has brought to my attention that phasor~ now has a lock attribute which might be useful for many things in this area. I think it's time to go through all the help patches of the objects I use again - so many hidden gems to find!

yes, i too discover new hidden attributes all the time.. part of the fun i guess. good to know about the lock attribute to phasor~.

about the delta~ thing: actually the bang will happen at the start of the loop with both solutions since egde~ triggers only on the zero to non zero transition. see proof below.