Live's embedded Python cannot use threads; AbletonOSC polls the OSC socket once per 100ms tick using Live's scheduler

Ableton Live’s Python environment does not support standard Python threading — starting a background thread causes a ‘beachball’ hang. AbletonOSC works around this by using Live’s built-in scheduler: it calls self.schedule_message(1, self.tick) at the end of each tick, scheduling the next socket poll ~100ms later. On each tick, it calls osc_server.process(), which drains all queued UDP datagrams non-blockingly. This means AbletonOSC has a maximum effective response latency of ~100ms between a message arriving at the socket and Live acting on it. Property listeners fire immediately when the Live object changes (they use Live’s own internal notification system), so listener-push latency is much lower than poll-cycle latency.

Examples

The tick pattern in manager.py: def tick(self): self.osc_server.process(); self.schedule_message(1, self.tick). The docstring notes it is ‘Called once per 100ms tick’. The client’s TICK_DURATION default (0.150s) accounts for this latency plus processing overhead.

Assessment

Why can’t AbletonOSC use a background Python thread to read the OSC socket? What is the worst-case latency for a command sent via OSC to take effect in Live? Is listener push latency affected by the same limit?