There was a subtle issue when cutting (using cut numbers other than 0), that sometimes a note would hang. This happened because several cut numbers were sent to the same synth group (especially when using negative cut numbers for cutting across orbits). Because all controls are set within a block and only then are called, they stepped onto each other's feet. Now the "clean" way to solve this would have been to keep a list of all running synths and then free them if any matches a given cut number. But superdirt avoids such neurotic housekeeping at all cost.
The result is a hack, with a minor disadvantage: there are tiny gaps between the cut and the next sound, which become larger with the absolute value of cut.
The precise timing of every cut depends on its cut number. The higher the cut number, the earlier the cut will happen. How much this is, you can calculate from the block size and the sample rate: ~cut.abs * server.options.blockSize / server.sampleRate, so for example for 48kHz sample rate and the default block size, # cut 1 we will cut 1 * 64 / 48000, which is about 0.0013 seconds. You have to try if that causes problems, but the impact seems pretty small. With very large cut groups, like above 200, you'll see a warning: you then need to increase the latency in tidalcycles.
I've merged this in the developer branch of SuperDirt, so if you work a lot with cut groups, please try it out and let us know!
Now after some thinking fore and back, here is a new solution. It works reliably. The disadvantage is that cuts now cost more in sclang (about double, at least in very dense situations), less on the server. But I still think it is the best solution.
As someone who is fairly English, I didn't know the particular etymology/meaning of either, but only know it as the phrase 'flotsam and jetsam' meaning something like random nonsense.. not really heard either on their own. 'flotsam' feels more familiar though, I guess because it comes first in the phrase. I'd say either is fine!
… well, I have to say I am still a bit undecided. For very high loads (around 1000 cuts/sec), the flotsam version may get unstable, while the current one in develop seems to be ok. But there is still the possibility of a dropped cut.
I'll keep the pull request open and let everyone test both variants.