No song position data between Reason 11 and Max 8 using [rtin]?

song position is a 'system common message', not realtime.
So it may not be received with [rtin], try using [midiin].

Ah, many thanks. Yes, I see messages coming out of [midiin] that look like this:

print - 242
print - 0
print - 0

That '242' looks like exactly what I was looking for. The 2nd value appears to be the position of the song in ticks (it is 0 in the example above, but this value changes if I start the song somewhere other than the beginning-- it is 16 if I start at measure 1, 32 at measure 2, etc.

Can anyone explain what the 3rd number might be? It seems to be always 0.

The song position pointer counts in steps of 1/16 notes. So you get 16 after 1 bar at 4/4. But as one midi byte can count only from 0 to 127, a second byte is needed and the value is calculated with the formula "byte1+128*byte2".
For example, after 10 bars at 4/4 the song position would be:
160 represented by the midi message 242 32 1.

Thanks for that explanation, and that formula looks key. I'm pretty new to Max, so would also like to ask for help on how to handle the 3 messages being sent from [midiin], to listen for the 1st of these messages to be 242, and when that occurs to take the next 2 messages, perform the math operations needed, and spit out a final song position value. I've got a grip on the [*] and [+] objects to do the math for me, it's just the handling of the sequence of messages that has me stumped. Thanks for any additional help!

here is patch with midi clock and SPP both send and receive.

Wow, many thanks! This looks much more robust than what I had cobbled together.

I feel that I'm prettty close to my goal of building a transport integration, but one thing still eludes me. How can I get the transport to set its tempo to match the incoming MIDI tempo? It appears that 'set tempo' midi messages are meta so are not actually transmitted? What would the trick be to get the Max transport to recognize the tempo of the incoming MIDI data and then track it? Thanks again for your help, this has probably saved me a week of research.

why would you track tempo ?
midi clock is running the progress of the ticks,
in my opinion transport would just be disturbing.
If you want to measure incoming tempo
you could bang timer from incoming ticks (sel 248)
and expr 60000($f1*24) to get bpm, but it will fluctuate
and won't be really reliable if one uses float tempos in .00 range
adding round object could also help.

but if you want transport ...

Hi and thanks again, this is really helpful.

My goal is to get Max's transport to 'shadow' Reason 11, so that if I set loop points in Reason the Max transport will loop on those measures as well, if I change tempo in Reason, Max will be able to follow along at the new tempo, and if I scrub to a specific point within Reason, Max will update its position in the transport accordingly.

The latest patch provided doesn't seem to track the tempo coming from Reason. If I set a 4 bar loop in Reason at 200bpm, the patch provided's transport counts up to about 6 bars then resets to the beginning at the loop point, and then just stays at 'start of the track' rather than continuing. I'm hoping to have something that will be able to know Reason is at 200bpm and will set the transport to match that, as well as when the song position is reset to the beginning of the track or some other point that the transport will update its position to match and continue to play back at the current tempo. I also found the transport's 'tempo' outlet and it is currently reading about 73bpm rather than 200.

Can you advise me on how to achieve these things based on the last patch provided, or one of the other previous patches provided?