schlam

feeding a live observer with the path "live set master track mixer device song tempo" outputs the right Live's tempo.

But when switching "Ext" on, Live.oberver doesn't output the current tempo anymore..

"Current tempo of the Live Set in BPM, 20.0 ... 999.0. The tempo may be automated, so it can change depending on the current song time."

It is a bug that live.oberver cannot observe the "Current tempo of the Live Set" if this tempo is synch to Ext. It should still be the "Current tempo of the Live Set" ??

In other words, is there a way for a m4l device to observe Live's tempo even when "Ext" is on ?

Hello,
Everything is in the title.
feeding a live observer with the path "live set master track mixer device song tempo" outputs the right ... 

live-oberver-stop-observing-live's-tempo-when-ext-sync-is-on-bug

I don't think it's a bug but a design issue. Live disables all play control functions when synced to Ext. Notice that the tempo field is greyed out and you can't stop the transport. Other DAWs (eg. Logic) behave differently.

If it's not a bug it's worst, it's a really bad design =)

Yes, like some DAWs, stop button is greyed when EXT sync is on, ok, but what is the link between an external syncronisation and the fact that the current Tempo of the daw cannot be observe anymore ?

I really don't see a situation where it's a good design that the property "tempo" cannot be observed (just observed, even not set..) when this tempo is synchronize elsewhere.. This tempo, at this moment, IS the tempo of Live.

Does that mean that it's impossible to have any m4L device that works function to the current live tempo when EXT is on...

Well, I would think it is one thing to indicate a tempo to a machine so that some internal processes can calculate the inverse length of each beat and count the time to trigger the next beat. It is a different thing while beats are coming in, to measure the length each one takes, to calculate a tempo from that and then to decide how to display it. Process prioritisation as well as the presentation of micro deviations (like subtle changes between 119.99998 and 120.00001) come to mind.

While I am fully aware why you as a user would want that I can also see why a developer will see this as a non-trivial extra complication, distracting her from more fundamental details. After all, should't we expect the device that produces the beats to be able to indicate its tempo?

Well, I would think it is one thing to indicate a tempo to a machine so that some internal processes can calculate the inverse length of each beat and count the time to trigger the next beat. It is a different thing while beats are coming in, to measure the length each one takes, to calculate a tempo from that and then to decide how to display it. Process prioritisation as well as the presentation of micro deviations (like subtle changes between 119.99998 and 120.00001)  come to mind.

I am aware that calculating a tempo is not simple but here it is not the problem I think.

The only thing that bothers me it's while the tempo is well calculated and the value is available/readable in the "tempo numbox" of Live, this value is not sent to the API and cannot be known by a device.

EDIT : cycling'74 support think it's a bug, they can reproduce and will investigate.

Thank you Ingmar.
I am aware that calculating a tempo is not simple but here it is not the problem I think.

Thank you for your suggestion SOURCE AUDIO

plugsync~ reports correctly the tempo while EXT is on.

At the end, if I want to observe Live's tempo while EXT is on, it's to find a workaround for another problem. I open 

Thank you for your suggestion SOURCE AUDIO
plugsync~ reports correctly the tempo while EXT is on.

At the end, if I want to observe Live's tempo while EXT is on, it's to find a workaround for another problem.  I open another topic for this other question.

live.oberver stop observing Live's tempo when Ext Sync is on.. Bug ?