This is the same as the variable-resolution issue that we talked about before.

When you create the pattern object, ~bus gets immediately resolved to its concrete Bus object.

The pattern retains no magical link back to the bus variable.

If you change the bus variable’s referent to a new Bus, the pattern could only pick that up if it has a magical variable link. But there is none!

You can explicitly create a link by \bus, Pfunc { ~crazy } – this isn’t magical because it’s written out :wink:


Unfortunately, I’m not sure exactly what in my post you’re referring to…

You will only have as many reverbs as you instantiate. It has nothing to do specifically with a SynthDef or not. SuperCollider has no idea what an effect is, or what a voice is, or etc. This are distinctions that you’re making (and me too). A SynthDef doesn’t even technically have to make or modify sound at all.

So, if you instantiate only one reverb, and route all your voices into it, that’s what it’ll be. Using bus 30 & 31 or 0 & 1, or which ever you decide upon, it’s no different. All running voices are routed to whichever bus you specify. If you use Out for all the voices, the effect is that they will be summed on their respective bus. If that bus so happens to have your reverb at the end of the chain, so be it.

Check out those help files. And it also matters that the reverb is last in the chain of all your nodes, regardless of which bus it’s listening to, and which bus you’re sending your voices.

I tried running the code from your screenshot (as best as I can guess, since you’re running things out of order), and I can’t reproduce this problem.

At this point, there is too much guesswork. For example, when you’ve written Pdef(\crt).play(t) before t = TempoClock..., then I have to guess how you’re executing it. Probably I’m not doing the same thing that you are. Or possibly you ran something 30 minutes ago and forgot about it, and it’s affecting the current results.

So I would suggest to collect the actual instructions that you’re running. Then post those.

// start from scratch! completely from scratch!
// make sure there is absolutely nothing left over from some other code bit



// ... now do the things here...



Now you should have a new tab in the editor with:

// History, as it was on Wed Jul  6 08:22:40 2022.

// - 0:0:0.0 -  
SynthDef(\Reverberate, {
	|in = 30, out = 0, mix = 1|
	var signal, processed;
	signal =, 2);
	processed =, mix:mix);
	processed = (signal+processed)*0.5;
	processed.debug("reverb shape");, processed);

// - 0:0:2.02 -  
~bus =, 2);

... etc...

You’re not going to get any concrete answers to these questions unless we know concretely, exactly, what you’re doing, in what order.


1 Like

What’s out of place in the example ?
It’s just the standard reverb with an instrument ( which can be anything you want).
A synth to launch the effect and a var to free it .
A bus variable and free bus
The Pdef(/crt).play(t) is bound to tempo
Tempo code seems good to
What code exactly is out place ?
Will upload snippet later

Going back to the latest posted example

  • Pdef(\crt) uses \bus, ~crazy but ~crazy =, 2) is all the way at the end. Running the statements in order, Pdef(\crt) plays nothing because \bus is being populated by nil.
  • Pdef(\crt).play(t) is written before t = TempoClock... so, if I run the statements in the order written, it plays at 60 bpm, not at 126 bpm.

So what is the order? Logically it would be SynthDef first, bus creation second, Pdef definition third, TempoClock creation fourth, Pdef(\crt).play fifth… but it isn’t written that way, so I don’t actually know what you’re doing. (And, the fact that you’re getting inconsistent behavior at different times suggests that the order in which you are running the statements is also not consistent.)

The code as written may be a useful notation for yourself, but it isn’t communicating accurately to other people. In this context, accurate communication is important.


See also Bus routing: ddwMixerChannel's approach


About the order of statements , doesn’t that only make sense when you’re executing them all at once or on start up .
Done manually
I evaluate tempoclock first , then the reverb, followed by synthdefs and lastly the pdefs and pdefs play .
Always worked till now

Just started up the pc, a single sine osc !2
Notice the audio level input
As I explained earlier , when I started two years ago with supercollider , it would only start up if it had acces to the microphone .
I had to make these settings in windows system settings , perhaps that is the reason why there is always a signal on bus 2.3
yep , it’s def. the microphone setting , I just turned it OFF in windows and SC gives me the following message

Booting with:
SC_PortAudioDriver: PortAudio failed at Pa_OpenStream with error: ‘Unanticipated host error’
could not initialize audio.
Server ‘localhost’ exited with exit code -1073740791.


For your personal use, that’s correct.

In context of this thread, you’re raising questions about differences in behavior between slight variations in the code.

To analyze the reasons for the different behaviors, it’s necessary to know exactly what was run, in what order.

If you write the code in the order 1-5-2-4-3 but executed it in the order 1-2-3-4-5, then it’s going to be harder for anyone else to understand the scenario.

This increases the probability of you receiving irrelevant or wrong answers (wasting time).

Help us to help you better.

Ok. For like the third time in this thread.

The audio input buses are always on.

They are always getting a signal from the soundcard.

You cannot turn this off. (Please stop trying to turn this off.)

Actually it just occurred to me – the fact that you see it in the level meter means that it must be coming from outside of SC. The level meter places the input-meter synth first in the chain (and the output-meter synth last). Therefore the input level being shown should be unaffected by any SC audio processing. If it’s unaffected by SC processing, then the level meter isn’t showing SC audio in the hardware input buses. Thus any nonzero audio in the hardware inputs must be external to SC.

If it’s external to SC, then it isn’t reflecting any bugs or weird behavior in SC. So there’s really nothing to worry about.

“But there’s a signal there and I don’t need it” – there is a simple solution to this: just don’t read from those buses.


I was mostly talking about wet dry processing in general
Most of the time I am sequencing with Pdefs ,
Synthdef (for synth ) has one with a bus effect argument , another output to main output , thus arg 0
When sequencing the synthdef from Pbind ,\out,~effectsbus , the other in the synthdef itself provides the dry signal and no need to add this one in thePbind .
So far it’s working o.k. , just asking what the preferred method is

		var sig ,modulator;,2);*modamt;,mdt,dt+modulator,dect);,hpf);,sig)

~comber=Synth(\layla,[\in,~speak,\mdt,0.5,\dt,0.01 ,\dect,0.8 ,\modspeed,0.8,\modamt,0.001,\hpf,100])
~comber.set(\mdt,0.5,\dt,0.01 ,\dect,0.8 ,\modspeed,0.8,\modamt,0.001,\hpf,100)//comber
~comber.set(\mdt,0.5,\dt,0.450 ,\dect,10 ,\modspeed,0.01,\modamt,0.001,\hpf,100)//  long delay

SynthDef (\simple,
var sig,env;[0,1,0],[att,dec],[0,-5]),doneAction:2);,mul:0.5),mul:0.5);///////I an,filterfreq+(env*mod).clip(40,20000),rq:reso);
		sig=sig*env;,pos:pan);,sig*vol);//to effects bus ~speak,sig*vol);//to main out



This is also a method for changing the out in a Pdef
~speak is a bus variable
Using ~change in the pdef , changes between a totally wet and dry signal , ofcourse the pdef needs to be re-analyzed for changes to take effect .
Is it a no-go to assign a variable to an already declared variable ?
It works pretty well

~change=~speak//effects bus,2);//creating new audio bus 
~change=~buss_10//switching to new audio bus 
~change=0///will set to main out 
~change=~speak//will set to ~speak bus which houses the effect 
		\amprel,Pwhite (0.08,0.3,inf),
SynthDef(\myFx, { |bus, mix|
    var sig =, 2);
    var wet = ... your fx processing...;,, wet, mix * 2 - 1));

I usually start with a template like this. All other options will be more complicated IMO.


I don’t get why there is the same bus arg for the Replace.out ,wouldn’t 0 be suffice to route the effect to the main out ?
When I set the out of an effects to the same arg as it’s input ( like yo do in your example ) I hear nothing because the effect stays on that bus
Here’s a simple distortion effect
Set out to arg.bus and you won’t hear the processed sound

   	var sig;,2);


IMO the simplest way to write fx inserts is to keep them on the same bus.

Then use another synth for the routing.

You’re probably thinking that another synth for routing is a complication. Actually I find that a more modular design ends up being simpler to use and debug. This is consistent with general findings in computer science.

I spelled it all out in the other thread, with a complete demonstration. Actually I wrote that thread for you.


Am I right in thinking that the oscilloscope busses actually show the signal that is GOING INTO the bus and not leaving the buss ( so processed )
For demonstration purposses I kept it as simple as possible
A synthdef saw wave going into a Synthdef hp filter
Synthdef saw out=nr 10
Synthdef hpfilter effect in =10
Looking at the scope on bus 10 we clearly see an unfiltered signal
The actual processed output appearing in the speakers is clearly filtered

		var sig;,2);,freq:cutoff,rq:reso);


{ |out,freq=60,vol=0.5,att=0.001,dec=0.250|
var sig,env;*vol;[0,1,0],[0.001,0.250],[0,-5]),doneAction:2);

Could you please answer why your last posted effect code has the same argument for both input and output ?
If I do that , the effects stays on that bus

This is explained in the other thread, which describes my approach in full – Bus routing: ddwMixerChannel's approach

I took time to write that up because I see you struggling with this for like a week, and I thought it might help to describe a known, working approach from the ground up, which you could take bits of and imitate. It’s right there, waiting for you to take a look…


A week ? now let’s not exaggerate :slight_smile: ,it’s two days since I started exploring busses
I just thought there was something wrong because of the activity on channel 2-3 , it now works pretty well .
I haven’t even looked into groups etc…
Thanks for the write up ,about the mixer ,much appreciated

Really got a hold of the busses
For me the easiest is just to provide a Xfade ugen in the synthdef too xfade between processed and wet
Here I created 1 comdelay Synthdefeffect
Three variations all having their own bus

		var sig ,modulator,processed;,2);*modamt;,mdt,dt+modulator,dect);,hpf);,sig,xfadecontrol);,processed)
	\dt,0.01 ,
	\dt,0.450 ,
	\dect,44 ,
)//  long delay
	\dt,0.1 ,
	\dect,10 ,
	\xfadecontrol,0.7)//  long delay
	\dt,0.5 ,
	\dect,22 ,
	\xfadecontrol,0.8)//  long delay

Ahhhh hahahaha – you’re quite right. It’s been a very busy thread – I guess to me it felt like a week’s worth of conversation.

Hmmmm… I think the way that you’re doing it, you’re losing some control over the dry/wet ratio.

For a mix parameter to mean what you think it means, you need to keep all the signal processing for the channel on the same bus, and XFade2 + ReplaceOut.

Also, your SynthDef(\layla) makes it impossible to run different effect synths in series.