Closed WillB97 closed 2 years ago
General question: what's the plan for validating the latency consistency of the API this now uses?
General question: what's the plan for validating the latency consistency of the API this now uses?
Given the non-deterministic 23ms latency from the time it takes the lighting console to transmit a packet to the lights, the latency from sending a network packet will be negligible. Timeit measures 8us to construct and send the packet.
General question: what's the plan for validating the latency consistency of the API this now uses?
Given the non-deterministic 23ms latency from the time it takes the lighting console to transmit a packet to the lights, the latency from sending a network packet will be negligible. Timeit measures 8us to construct and send the packet.
For clarity: what meant here was the full stack latency (agree that local packet construction time is going to be tiny), though I hadn't realised there was non-deterministic downstream of the lighting controller.
This was used for smallpeice 2022 and worked flawlessly. The magicq support is much more reliable.
Open Sound Control (OSC) is a more universal protocol for automating AV equipment. Magicq also works more reliably with OSC than its proprietary Remote Ethernet Protocol.
Also happens to solve #5.