cut/orbit interaction bug about superdirt

[bgold-cosmos]

I haven't had any problems so far, so I think it should be OK for 0.9-dev.

[fdragovic]

does this mean the dirt channels should automatically be in seperate orbits or that the cut should work on the d1,2,3 groups instead of on orbits...

[bgold-cosmos]

Cut is supposed to work on anything in the same "cut group", which is the number parameter you give cut. The d1,2,3 grouping shouldn't matter. So in d1 $ sound "rave foo" # cut "1" the samples should cut each other just the same as if you'd done d1 $ sound "rave" # cut "1" and d2 $ sound "~ foo" # cut "1".

[fdragovic]

you're right, what I said makes no sense now sorry!

[telephon]

Trying to first reproduce it, I wrote these:

-- d1 long
d1 $ gain "1 0 " # sound "h:0" # cut "1" 

-- d1 short d2 short (same cut group)
d2 $ gain "0 1 0 0" # sound "h:0" # cut "1"

-- d1 long d2 long (other cut group)
d2 $ gain "0 1 0 0" # sound "h:0" # cut "0"

-- d1 long d2 short (same cut group)
d1 $ gain "1 0 0 0 0" # sound "h:0" # cut "1"

Is this correct so far?

[bgold-cosmos]

I don't know if that's showing the odd behavior I'm seeing.

I also realize I was overlooking that the use of gain zero samples here absolutely should cut other samples. So as a more minimal example:

cps 2 -- to make it more obvious

d1 $ gain "1 1 1 0" # sound "h:0" # cut "1"

d2 $ gain "1 1 1 0" # sound "h:0" # cut "2"

Individually, those each sound as they should. But play them together and it seems like the cut stops working entirely. However if I explicitly put d1 on orbit 0, and d2 on orbit 1, then it works again.

Playing around just now, it also works as expected if I nudge one of them at least 2 milliseconds. So I guess there's an issue with simultaneous cut messages coming into the same orbit? Some kind of race condition?

[telephon]

Ah that is a good clue. It is possible that two messages that happen within one block (e.g. 64/44100 s) override each other.

I just tried:

s.options.blockSize = 2;

s.reboot;

An then start superdirt again.

Then the problem (almost) disappears.

I'll take a look. Either it can be solved in the envelope generators or we have to send a channel id (or name) from tidal – which might be a good idea anyway? But even then, you may get such issues with functions like jux.

[telephon]

The core of it is this supercollider implementation problem: one message overrides the next message if it comes within one block.

Compare:

// run a silent synth
a = { |gate=1| FreeSelf.kr(1 - gate) }.play; a.onFree { "synth ended.".postln };

// set the gate to 0. This frees the synth.
s.sendBundle(0.2, ["/n_set", a.nodeID, "gate", 0]);


// run a silent synth
a = { |gate=1| FreeSelf.kr(1 - gate) }.play; a.onFree { "synth ended.".postln };

// set the gate to 0, then to 1. This doesn't free the synth.
s.sendBundle(0.2, ["/n_set", a.nodeID, "gate", 0],  ["/n_set", a.nodeID, "gate", 1]);



// run a silent synth
a = { |gate=1| FreeSelf.kr(1 - gate) }.play; a.onFree { "synth ended.".postln };


// set the gate to 0, then to 1, but with 0.1 s time difference. This frees the synth.
(
s.sendBundle(0.2, ["/n_set", a.nodeID, "gate", 0]);
s.sendBundle(0.21, ["/n_set", a.nodeID, "gate", 1]);
)

It has been a long standing issue, I am not sure how long it'll take to be solved in supercollider – it has to do with the basic infrastructure.

We may be able to solve it with much more bookkeeping on the sclang-superdirt or even tidal side, but I'd like to try to avoid that. Let's see.

Any ideas?

[bgold-cosmos]

Yes, I was about to post that it looks like gateCutGroup and gateSample are control rate parameters, and updates within a block clobber each other. Changing them to audio rate doesn't actually fix things, either.

Is it possible to move some of the "cutting" functionality to be more like a per-sample effect? Right now it's done with the mixing in \dirt_gate, I don't know what it would look like to separate things.

[telephon]

The cutting functionality is per sample. The mixer is a single grain, one mixer per sample ...

[telephon]

For reference, I've made an issue here: supercollider/supercollider#2501

[telephon]

Can you try how #28 works for you?

[bgold-cosmos]

Gave it a quick check and it passed the obvious tests - I'll continue to hammer at it.

[bgold-cosmos]

Using #28 now everything on the same pattern seems to cut itself, regardless of what parameter I specify. Actually, I'm not sure it's the cut mechanism, it seems that the sample stops playing at the end of its pattern "slot". For example d1 $ sound "rave ~" will cut itself off after half a cycle. I don't think this happened before.

[telephon]

ah ok, I'll check.

[telephon]

if you like, try again (I've got no time to test it right now).

[bgold-cosmos]

It's still doing it - I'll try to investigate why. It's somehow not directly related to cut, for example these two now sound very different (the latter cuts off much sooner):
d1 $ sound "rave"
d1 $ sound "rave ~ ~ ~"

[bgold-cosmos]

OK, it seems this is because of ~legato = 1.0 in the default Event, which is causing the sustain calculation in calcRange to kick in. I don't understand why I didn't run into this before, though.

[bgold-cosmos]

Ah, I see that this was done in prior commit. It seems like what we really want is ~legato to be nil for samples, but default to 1.0 for synths.

[telephon]

oh dear, yes. I hope it is fixed now.

[bgold-cosmos]

One last thing - since ~delta is now already folded into unitDuration, it can be removed from the sustain calculation line:

    sustain = ~sustain ?? { if(~legato.notNil) { ~legato * unitDuration } { unitDuration } };

I think then everything works as expected.

[telephon]

yes, you are right. But that is for synths, not for samples.

[bgold-cosmos]

Ah, I think I get the intended behavior now. Then I think what works is to get rid of the unitDuration instead of the ~delta:

    sustain = ~sustain ?? { if(~legato.notNil) { ~delta * ~legato } { unitDuration } };

Otherwise you wind up double-counting the delta.

[telephon]

OK, then the ~legato overrides ~length – need to think a little bit whether that's giving away too much, but it is simpler that way.

… there are so many sustain related parameters now!

[telephon]

so this should be in for now...

[telephon]

@bgold-cosmos did this fix make it consistently work for you? Just wondering if I should merge it into 0.9-dev