cut groups break on simultaneous events

[geikha]

The following code acts as if there were no cut groups indicated at all:

d1 $ superimpose ((# speed 2) . (# cut 2))
        $ s "bev(6,8)" # cut 1

It should sound like

d1 $ s "bev(6,8)" # cut 1

d2 $ s "bev(6,8)" # speed 2 # cut 1

It seems it also doesn't work like this:

d1 $ stack[
    s "oregano2(6,8)" # cut 1,
    s "oregano2(6,8)" # speed 2 # cut 2 
]

So it seems the cut groups are broken?

[bgold-cosmos]

Did you mean # cut 2 on the last line? Because the cut 2 in the first example will supersede the cut 1 for the superimposed pattern.

[geikha]

@bgold-cosmos sorry do you mean the last line of the last example or the last line of the first example?

either way, doesn't matter. what i've written it's what i meant :P

in the first example i want to have two different cut groups. one cutting the original and the other one cutting only the sped up samples. as for last example, each orbit has its own cut groups so it really doesn't matter which non-0 number i put in there.

[bgold-cosmos]

Ah sorry, I forgot about d1 and d2 being different orbits by default.

Looking into this I think it may stem from #252 since I don't think there was a problem previous to that change, but I can't easily see why the new code shouldn't work. I'll try verifying some test cases and see if I can't figure out more clearly what's going on.

[bgold-cosmos]

OK, still working on a fix, but it definitely appears to be an issue with the handling of simultaneous cut messages. Shifting things even slightly causes it to work:

d1
 $ stack [
  s "bev(6,8)" # cut 1 # shape 0.9,
  ((1/1024) ~>) $ s "cp*8" # cut 2
  ]

is fine, but change the 1/1024 to 0 and the cut gets obliterated

(edited to add): also to be clear, this is a regression - the issue doesn't happen in an older branch I have from 2021

[telephon]

Yes, at #252 we removed the cut group for each orbit, and maybe something else went wrong.

[telephon]

@bgold-cosmos If you switch on dump osc on the supercollider side, what messages do you see?

The key is somewhere either in DirtGateCutGroup:

DirtGateCutGroup {

	*ar { | releaseTime = 0.02, doneAction = 2 |
		// this is necessary because the message "==" tests for objects, not for signals
		var same = { |a, b| BinaryOpUGen('==', a, b) };
		var or = { |a, b| (a + b) > 0 };
		var and = { |... args| args.product };
		var sameSample = same.(\sample.ir(0), \gateSample.kr(0));
		var sameCut = same.(\cut.ir(0), \gateCut.kr(0));
		var free = and.(or.(\cutAllSamples.kr(0), sameSample), sameCut);
		^EnvGen.kr(Env.cutoff(releaseTime), (1 - free), doneAction:doneAction);
	}
}

and in DirtEvent:

if(~cut != 0) {
				server.sendMsg(\n_set,
					if(~cutAll.notNil) { orbit.dirt.group } { orbit.group },
					\gateSample, ~hash,
					\gateCut, ~cut.abs,
					\cutAllSamples, if(~cut > 0) { 1 } { 0 }
				)
			};

, and finally here:

sendGateSynth {
		server.sendMsg(\s_new,
			"dirt_gate" ++ ~numChannels,
			-1, // no id
			1, // add action: addToTail
			~synthGroup, // send to group
			*[
				in: orbit.synthBus.index, // read from synth bus, which is reused
				out: orbit.dryBus.index, // write to orbital dry bus
				amp: ~amp,
				gain: ~gain,
				overgain: ~overgain,
				sample: ~hash, // required for the cutgroup mechanism
				cut: ~cut.abs,
				sustain: ~sustain, // after sustain, free all synths and group
				fadeInTime: ~fadeInTime, // fade in
				fadeTime: ~fadeTime // fade out
			]
		)
	}

[telephon]

I'm trying to reproduce this on the sclang side.

All this seems to work fine:

SuperDirt.default = ~dirt;

// cut same cut group, correct
(
fork {
	(type:\dirt, orbit:0, s: \sax, cut: 1).play;
	0.2.wait;
	(type:\dirt, orbit:0, s: \cr, cut: 1).play;
}
)

// don't cut different cut group, correct
(
fork {
	(type:\dirt, orbit:0, s: \sax, cut: 1).play;
	0.1.wait;
	(type:\dirt, orbit:0, s: \cr, cut: 2).play;
}
)

// don't cut different cut group, simultaneous, correct
(
fork {
	(type:\dirt, orbit:0, s: \sax, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 2).play;
}
)

// don't cut different cut group, absolutely simultaneous, correct
(
s.bind {
	(type:\dirt, orbit:0, s: \sax, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 2).play;
}
)

// cut same cut group, absolutely simultaneous, correct
(
fork {
	(type:\dirt, orbit:0, s: \sax, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 1).play;
}
)

// cut same cut group, absolutely simultaneous, correct
(
s.bind {
	(type:\dirt, orbit:0, s: \sax, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 1).play;
}
)

[telephon]

@bgold-cosmos maybe you can find a minimal reproducer and then check in tidal what the actual events are that are being sent?

[bgold-cosmos]

@telephon
The Tidal events look fine, its seems that when there are two bundles with the same timestamp that one n_set will override the other?

To see this on the sclang side, I think you need to have some cutting going on in each group. I notice an issue with this:

(
fork {
	(type:\dirt, orbit:0, s: \bev, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 2).play;
	0.3.wait;
	(type:\dirt, orbit:0, s: \bev, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 2).play;
}
)

You'll hear two overlapping "bev" samples playing, which should not be happening.

Minimal Tidal code to do something like this is

d1
 $ stack [
  s "bev*8" # cut 1,
  ((0/1024) ~>) $ s "cp*8" # cut 2
  ]

Looking at the OSC dump in supercollider it look like

[ "#bundle", 16676975298944028671, 
  [ 12, 1004, 1 ],
  [ 15, 1004, "resumed", 1 ],
  [ 12, 1003, 1 ],
  [ 15, 1003, "resumed", 1 ],
  [ 12, 1001, 1 ],
  [ 15, 1001, "resumed", 1 ],
  [ 12, 1000, 1 ],
  [ 15, 1000, "resumed", 1 ],
  [ "/n_set", 3, "gateSample", -1128873534, "gateCut", 1, "cutAllSamples", 1 ],
  [ "/g_new", 1098, 1, 3 ],
  [ "/s_new", "dirt_sample_1_2", -1, 1, 1098, "bufnum", 520, "sustain", 16.0552, "speed", 1, "freq", 261.626, "endSpeed", 1, "begin", 0, "end", 1, "pan", 0, "out", 34 ],
  [ "/s_new", "dirt_gate2", -1, 1, 1098, "in", 34, "out", 36, "amp", 0.4, "gain", 1, "overgain", 0, "sample", -1128873534, "cut", 1, "sustain", 16.0552, "fadeInTime", 0, "fadeTime", 0.001 ]
]
[ "#bundle", 16676975298944028671, 
  [ 12, 1004, 1 ],
  [ 15, 1004, "resumed", 1 ],
  [ 12, 1003, 1 ],
  [ 15, 1003, "resumed", 1 ],
  [ 12, 1001, 1 ],
  [ 15, 1001, "resumed", 1 ],
  [ 12, 1000, 1 ],
  [ 15, 1000, "resumed", 1 ],
  [ "/n_set", 3, "gateSample", -1175928170, "gateCut", 2, "cutAllSamples", 1 ],
  [ "/g_new", 1099, 1, 3 ],
  [ "/s_new", "dirt_sample_1_2", -1, 1, 1099, "bufnum", 715, "sustain", 0.445122, "speed", 1, "freq", 261.626, "endSpeed", 1, "begin", 0, "end", 1, "pan", 0, "out", 34 ],
  [ "/s_new", "dirt_gate2", -1, 1, 1099, "in", 34, "out", 36, "amp", 0.4, "gain", 1, "overgain", 0, "sample", -1175928170, "cut", 2, "sustain", 0.445122, "fadeInTime", 0, "fadeTime", 0.001 ]
]

The only difference I can see from this and the similar dump from a working situation is here the two bundles have the same stamp.

[telephon]

Here is a shortened one:

(
fork {
	(type:\dirt, orbit:0, s: \bev, cut: 1).play;
	0.3.wait;
	(type:\dirt, orbit:0, s: \bev, cut: 1).play;
	(type:\dirt, orbit:0, s: \cr, cut: 2).play;
}
)

I think I know now. The group gets set with cut 1 and cut 2 in one block of calculation and it overrides before anything could happen that would have freed the first one.

OK, will think of a solution, may need some reworking.

[telephon]

I think there is no other way than to go back to the more complicated separate cut groups. I wonder if we could use the occasion to use them for something else as well.

[telephon]

One difficulty is that currently we are able to cut across orbits. That was a feature of the current approach that we lose if we implement the cutGroups as server groups: every orbit must have its own group, but one group can't live in several groups.

It would be possible to keep track of every synth, but that causes a lot more messaging (for freeing them when they are done).