Glicol uses the LCS algorithm to update only changed nodes when code is re-evaluated

Glicol’s engine uses the Longest Common Subsequence (LCS) algorithm as a preprocessing step when code is edited live. Rather than tearing down and rebuilding the entire audio graph on every keystroke or evaluation, LCS diffing identifies which nodes were added, modified, or removed, and applies only those changes to the running graph. This allows smooth, glitch-free transitions during live performance when a performer edits a node — unchanged nodes continue producing audio while only the modified parts are re-initialised. This is a ‘declarative’ execution model: the programmer describes the desired state and the engine reconciles it against the running state.

Examples

Changing the frequency in o: sin 440 to o: sin 220 while audio is running: only the frequency parameter of the sin node updates; other nodes in the graph are untouched.

Assessment

Explain why a naive ‘stop everything, restart’ approach to live code evaluation creates audible artifacts. How does LCS diffing avoid these and what cases does it not handle gracefully?