Thanks for the concise response.
Lab condition testing is fine as a guideline, but take a typical live situation:
You are running ableton, jamming in session mode, you are sending midi clock to one or more musicians that use ableton-laptops or hardware. Sooner or later, while using multiple instances of a CPU intensive plugin like e.g. turnado, your computer will have a ‘hiccup’ and miss a beat. Ableton’s midi clock will slow down and speed up again briefly, which will not be neutralized (or resynced) by the receiving devices. Within a split second, your co-musicians might be off by a quarter note, you might get a ‘snares on the one and three’ scenario. Everyone will have to resync to the first beat. I see this kind of thing happening on a regular basis. Ever since I’ve started insisting on being master clock with the OT, this problem has gone away, downstream to the slaved devices, to be precise. Hardware usually stays synced, laptops still have their hiccups, but not all clock recipients are affected by a master glitch…
Tbc. Off to dinner.
Ps. You could replace the term ‘hiccups’ with drop outs. The clock ticks might simply stop for a critical moment instead of changing speed too quickly.
In this case the mechanism of sync dysfunction is not as important as its result.