Audiobus(server,numchann)

[jamshark70]

@gentleclockdivider

And again there is audio on channel 2,3 ??

Asked and answered already – these channels come from your soundcard hardware inputs. You cannot turn them off in software. The only thing you could do is to use a USB soundcard with a level trim control and turn it all the way down. Even then it would be nonzero, just very small.

@gentleclockdivider

The reverb takes input from 30 ( nothing on that channel ), yet we still hear reverb ?

It doesn’t.

When you use ~bus without initializing it, then its value is nil.

So you’re sending an argument list [in: nil].

The server, for good or ill, treats nil as 0 in argument lists. So the server reads in: 0.

Using an uninitialized variable is generally not a good idea; I’m not sure why you are doing it here.

hjh

[gentleclockdivider]

My audio interface is a Roland integra , audio input is disabled and it is using USB .
When I just execute a synth from scratch from a fresh sc launch ( not using any busses at all ) channels 2 and 3 are Empty and there is NO signal present .
Only when using the ~bus routing ( which I posted in my previous post ) there is a signal on channel 2-3
See screen shot , just executing some Pbinds , everything is as expected on channel 0-1 and nothing more .
O.K so the server threads nil as bus 0 , well that says it all and is Nowhere explained .
The reason why I am not executing the ~bus was to find out whe there was a reverb , not knowing nil was treated as bus

[jamshark70]

@gentleclockdivider

See screen shot , just executing some Pbinds , everything is as expected on channel 0-1 and nothing more .

In the screenshot, the scope is starting at bus 2…? So that screenshot shows buses 4 and 5 silent, 2 and 3 with a signal.

My suggestion is to decide on the bus routing you want, and then just do it that way. I had proposed a best practice of: 1. Allocate bus objects for the channels you need. 2. Use these bus objects consistently for the corresponding arg names in synths and patterns. When implemented correctly, this works.

Deviating away from a set of reasonably good practices is quite likely to produce weird behavior. The thing is, it isn’t always necessary to understand exactly why the weird behavior happened. It may be enough to just stick closer to best practices. (Because, the number of permutations is very large, and the number of well-functioning permutations is much much smaller.)

Oh here’s one thing: sig=Pan2.ar(sig,pos:pan)!2; – double-stereoizing a signal – I’m not sure if that would cause bus spillover but this doesn’t look right.

hjh

[gentleclockdivider]

There is audio on bus 2-3 which are normally preserved for audio inputs , the local host meter also show activity on the input , and I can assure there is nothin plugged into my audio interface inputs .
All I know is that for supercollider to work it needs acces to the microphone (from windows system settings ) otherwise it wouldn’t start up

[gentleclockdivider]

@jamshark70

// huh, wait, you already mixed?
	// no need to mix again -- this line is unnecessary, deleting
	// processed = (signal+processed) * 0.5;

I didn’t mix two times
The dry signal is var signal which is incoming audio
The first processed lline of code is the dry signal 'sig’going through the reverb(mix set to 1 for 100% wet )
The second line of processed is the dry signal +processed , resulting in DRY+WET

(
SynthDef(\Reverberate,
	{
		|in=30,out=0,mix=1|
		var signal,processed;
		signal=In.ar(in,2);
		processed=FreeVerb.ar(signal,mix:mix);
		processed=(signal+processed)*0.5;
		Out.ar(out,processed);
}).add
)

[gentleclockdivider]

What’s the best use for dry wet processing
Right now I use bus for the processed signal , by using two out.ar in the synthdefs
one decidated to bus , and the other straight to bus 0 (dry )
In the pbind I can set the bus for the effect ~crazy , while the Synthdef also sends to 0

SynthDef(\twoop,
{
|fmamt=2,modoffset=24,moatt=0.001,modrel=0.500,ampatt=0.001,amprel=0.800,pitch=48,outt=0.3,pan=0.2,feed=0.2,bus|
var mod,modenv,ampenv,carr;

		mod=SinOscFB.ar((pitch+modoffset).midicps,feedback:feed)*fmamt;
		modenv=EnvGen.ar(Env.perc(moatt,modrel),doneAction:0);
		ampenv=EnvGen.ar(Env.perc(ampatt,amprel),doneAction:2);
		carr=SinOsc.ar(pitch.midicps,(mod*modenv))*ampenv*outt;
		carr=Pan2.ar(carr,pos:pan);
		Out.ar(bus,carr);
		Out.ar(0,carr);
}).add
)
/////////
(
Pdef(
	\crt,
	Pbind(
		\instrument,
		\twoop,
		\pitch,Pseq([40,52,40,49,37,42,42,56,54],inf)+7,
		\dur,Pseq([1/3,1/3,1/3],inf),
		\fmamt,Prand([2,1,3,4,2,1.5,2,3,4,6],inf),
		\modrel,Prand([0.425,0.525,0.500,0.550,1,0.625,0.500,0.5,0.8],inf),
		\modoffset,Prand([12,0,12,24],inf),
		\feed,Pwhite(0.3,0.5,inf),
		\pan,Prand([-0.3,0,0.3],inf),
		\amprel,Pwhite (0.08,1.0,inf),
		\bus,~crazy,

		)
	)
)
//////////

Pdef(\crt).stop;///////////FM

Pdef(\crt).play(t);
t=TempoClock(126/60).permanent_(true);
s.newBusAllocators;

(
SynthDef(\ffect,
	{|mdt=0.5,dt=0.1,modamt=1,modspeed=0.1,hpf=500,hpres=0.5,bus|
		var sig,modulator;
		sig=In.ar(bus,2);
		sig=RHPF.ar(sig,hpf,hpres);
		modulator=SinOsc.ar(modspeed,mul:0.5,add:0.0);
		modulator=modulator*modamt;
		sig=DelayC.ar(sig,mdt,dt+modulator);
		Out.ar(0,sig);

}).add
)

~dlay=Synth(\ffect,[\dt,0.001,\bus,~crazy]);
~dlay.free
~dlay.set(\dt,0.01,  \modamt ,0.5,  \modspeed ,0.5,  \hpf,600,  \hpres,0.1);
~dlay.set(\dt,0.01,  \modamt ,0.01, \modspeed ,100,  \hpf,500, \hpres,0.5);
~dlay.set(\dt,0.5,   \modamt ,0.01, \modspeed ,0.1,    \hpf,500, \hpres,0.5);
~dlay.set(\dt,0.01,  \modamt ,0.1,  \modspeed ,4,    \hpf,500, \hpres,0.5);
//////


~crazy=Bus.audio(s,2)
~crazy

[thresholdpeople]

@gentleclockdivider

There is audio on bus 2-3 which are normally preserved for audio inputs , the local host meter also show activity on the input , and I can assure there is nothin plugged into my audio interface inputs .

I believe it’s as jamshark mentioned in the previous post:

sig=Pan2.ar(sig,pos:pan)!2; in your Sqwer SynthDef that’s spilling over into your busses 2 & 3. If you remove the !2 from that line you should have the signal disappear from there.

[thresholdpeople]

@gentleclockdivider

What’s the best use for dry wet processing
Right now I use bus for the processed signal , by using two out.ar in the synthdefs
one decidated to bus , and the other straight to bus 0 (dry )

You have both dry and wet signal currently being output from the Reverberate Synth. Since this is the case, do you need the original dry signal to have its own output as well?

Do you want to have the reverb as the last part of your signal chain, or as an effect send?

If you just want it as the last part, you don’t need to set up different busses. It’s enough to have everything on bus 0, with Synth(\Reverberate, addAction: \addToTail) when you call the reverb.

Check out Order of execution | SuperCollider 3.12.2 Help, and especially the “Using order of execution to your advantage” section. Some parts about Routines may not be specifcally relevant to what you’re doing right now, but that section is specifically about routing, and routing several things through an effects processor.

If you take this approach, another important thing is which out UGen you use. You’ll likely want to keep using Out.ar as you have been for the main sound sources, but for the reverb, you’ll want to switch to ReplaceOut.ar. ReplaceOut | SuperCollider 3.12.2 Help

The way audio rate Out works (kr is different!) is that it adds its signal to the bus. So for instance if you had 6 instances of \twoop all running at the same time, the Out.ar that’s writing to bus 0 in your example, all 6 of those \twoops would mix together. It’s what you’d expect.

This is an issue for effects though. ReplaceOut doesn’t do this. It replaces all the signals on the bus.

If you want the reverb to act as an effects send, then the routing is going to be similar to what you’re doing now. I believe jamshark went into that approach in one of their earlier posts in this thread. You’ll still likely need ReplaceOut and contend with how out UGens write to busses.

[gentleclockdivider]

Just want to know if this is normal behaviour
If I free a bus ( example ~this bus ) and instantiate a new one ( same variable used ) , so new outputs are allocated
I also have to re instantiate all the pbinds that use ~this bus argument in order for it to point to the new allocated bus

[thresholdpeople]

That’s correct:

@semiquaver

When you use ~bus in the SynthDef, the interpreter resolves it before compiling the def. So whatever ~bus it is pointing to at the time you compile the synthdef gets coded into the synthdef and won’t change if you reassign ~bus. Same with Pbind.

Plus some more characters.

[gentleclockdivider]

If the !2 is responsible for the spillover ,Shouldn’t it then be going from 0-1 to 4-5 ?
Why would it spill over into preserved input busses ?
Will check tommorow if that’s indeed the case with the panner!2

[gentleclockdivider]

I am not sure if I am following you .
For every note a new synth is created , iow voices .
If all these are routed to a bus with an effect , the ( instantiated) effect just processes these voices , the effect remains mono or stereo .
It just processes the incoming audio stream , not every single voice
Are you saying that new effects are instantiated for every voice ?
I thought this only happens when the effect is part of the synthdef voice .
Forgive me if I misunderstood you.

[jamshark70]

@gentleclockdivider

Shouldn’t it then be going from 0-1 to 4-5 ?

No. A single Out unit will place its channels only onto consecutive bus numbers. You’re responsible for constructing those channels correctly (if you want stereo, don’t give it quad, for instance).

hjh

[jamshark70]

@gentleclockdivider

If I free a bus ( example ~this bus ) and instantiate a new one ( same variable used ) , so new outputs are allocated
I also have to re instantiate all the pbinds that use ~this bus argument in order for it to point to the new allocated bus

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

hjh

[thresholdpeople]

@gentleclockdivider

I am not sure if I am following you .
For every note a new synth is created , iow voices .
If all these are routed to a bus with an effect , the ( instantiated) effect just processes these voices , the effect remains mono or stereo .
It just processes the incoming audio stream , not every single voice
Are you saying that new effects are instantiated for every voice ?
I thought this only happens when the effect is part of the synthdef voice .
Forgive me if I misunderstood you

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.

[jamshark70]

@gentleclockdivider

There is audio on bus 2-3 which are normally preserved for audio inputs , the local host meter also show activity on the input , and I can assure there is nothin plugged into my audio interface inputs .

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
thisProcess.recompile;

History.clear.end;

History.start;


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


History.end;

History.document;

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 = In.ar(in, 2);
	processed = FreeVerb.ar(signal, mix:mix);
	processed = (signal+processed)*0.5;
	processed.debug("reverb shape");
	Out.ar(out, processed);
}).add
)

// - 0:0:2.02 -  
~bus = Bus.audio(s, 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.

hjh

[gentleclockdivider]

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
t=Tempoclock(124/60)_Permanent(true)
What code exactly is out place ?
Will upload snippet later

[jamshark70]

@gentleclockdivider

What’s out of place in the example ?

Going back to the latest posted example –

• Pdef(\crt) uses \bus, ~crazy but ~crazy = Bus.audio(s, 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.

hjh

[jamshark70]

See also Bus routing: ddwMixerChannel's approach

hjh

[gentleclockdivider]

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