Flotsam: change on cut in superdirt

This section is outdated, see below.

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!

4 Likes

Actually, I've been running this a little, the problem is just moved. Will need a better solution …

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.

Not yet pulled, but please feel free to try the flotsam branch!

Some discussion here: flotsam implementation by telephon · Pull Request #287 · musikinformatik/SuperDirt · GitHub

The solution introduces a new concept: flotsam. In the case of cuts, it breaks with an old policy not to track any synth groups. All running synth groups now live in a variable ~dirt.flotsam.

Should we find strong resons for tracking nodes in other cases, the mechanism is ready. But I'd try to avoid flotsam.

One question to all of you. The technically more correct term would be jetsam: these are things deliberately thrown off ship. But I am not English enough to know whether that is to arcane.

1 Like

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!

1 Like

I think I go with the more familiar then.

1 Like

… 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.

If there are no objections, I'll merge the floatsam branch into develop.

1 Like