It looks like desktop Safari has recently inherited iOS's behaviour where a new AudioContext is forced to remain in a "suspended" state until a user interaction occurs (in which resume() is called or a note is scheduled).
The synth-environment-tests and synth-removal-tests all assume that there is a viable, playing AudioContext. These tests, realistically, probably don't need this level of coupling—which probably should be saved for integration or manual tests that can include the requisite user involvement. Instead, these test should simply test what they say they do—whether or not synths get added or removed from the Flocking environment.
It looks like desktop Safari has recently inherited iOS's behaviour where a new AudioContext is forced to remain in a "suspended" state until a user interaction occurs (in which
resume()is called or a note is scheduled).The synth-environment-tests and synth-removal-tests all assume that there is a viable, playing AudioContext. These tests, realistically, probably don't need this level of coupling—which probably should be saved for integration or manual tests that can include the requisite user involvement. Instead, these test should simply test what they say they do—whether or not synths get added or removed from the Flocking environment.