Multichannel Control Bus setAt Bug

Development
1

Using SuperCollider 3.14.0-dev on Ubuntu 23.10:

~ctrl = Bus.control(s, 11)

(
{
	In.kr(~ctrl, 11).poll
}.play
)

~ctrl.setAt(1, 3)

The value at index 1 is 6, and always appears to be twice that of the set value.

And some more surprising behavior:

~ctrl = Bus.control(s, 2)

(
{
	~ctrl.kr.poll
}.play
)

Now after ~ctrl.setnSynchronous([1, 2]), the values are [1,2], but after ~ctrl.setn([1, 2]) the values are [2,4].

Best,Luc

2

On macOS, I can’t reproduce it. Here it is written in a simpler form:



~ctrl = Bus.control(s, 11)
~ctrl.get(_.postln);
~ctrl.setAt(1, 3)
~ctrl.get(_.postln);
3

I believe the problem will disappear if the polling synth isn’t outputting to the same bus that it’s reading.

(
{
	In.kr(~ctrl, 11).poll;
	Silent.ar(1)  // output
}.play
)

I’ve long been in the habit of putting a Silent at the end of every debugging synth like this one.

EDIT The problem disappears also if you ensure that you’re reading and writing different bus ranges.

s.boot;

~ctrl = Bus(\control, 1000, 11, s);

// now we are reading from 1000-1010
// and writing to 0-10
(
{
	In.kr(~ctrl, 11).poll(1)
}.play
)

~ctrl.setAt(1, 3)  // no doubled value

~ctrl.free;

hjh

4

Ah, that is it! Thank you both!

This is actually very interesting. @julian : It also shows how the syntactic form transforms what it is :slight_smile:

Intuitively, I would understand buses (audio or control) as “private”, so perhaps the fact that newly instantiated control buses start at index 0 by default is not desirable. Perhaps its something to think about/discuss.

5

Kr buses are private in the sense that there’s no hardware in/out for control buses.

I’m not sure I would advocate for SC’s main distribution consuming a few kr bus indices by default at startup. (How many buses to eat up? This example uses 11, which would be an arbitrary number to put into main SC. 2 might not be enough; 32 seems excessive, but on what basis could SC devs judge what is appropriate here?)

With that said, though, my live set init code does do ~dummyKr = Bus.control(s, 2) just after booting the server because it is actually dangerous to play a kr signal onto 0 when forgetting to specify a bus number, particularly when kr bus 0 would otherwise be the hwOut MixerChannel’s amplitude. (No, that filter frequency really should not jack up the main output by 70 dB.) However I’m taking my own responsibility for mitigating the danger, instead of expecting SC to anticipate each individual user’s configuration specifics.

Maybe it’s a documentation issue, then. We don’t have a “best practices that you might not think of on your own” document.

hjh