SuperCollider CLASSES

# In

Read a signal from a bus.

## Description

In.ar and In.kr read signals from audio and control buses, respectively. (See the Busses chapter of the Getting Started tutorial series for details on buses.)

In.ar and In.kr behave slightly differently with respect to signals left on the bus in the previous calculation cycle.

In.ar can access audio signals that were generated in the current calculation cycle by Synth nodes located earlier in the node tree (see Order of execution). It does not read signals left on an audio bus from the previous calculation cycle. If synth A reads from audio bus 0 and synth B writes to audio bus 0, and synth A is earlier than synth B, In.ar in synth A will read 0's (silence). This is to prevent accidental feedback. InFeedback supports audio signal feedback.

In.kr is for control buses. Control signals may be generated by Synth nodes within the server, or they may be set by the client and expected to hold steady. Therefore, In.kr does not distinguish between "new" and "old" data: it will always read the current value on the bus, whether it was generated earlier in this calculation cycle, left over from the last one, or set by the client.

Note that using the Bus class to allocate a multichannel bus simply reserves a series of adjacent bus indices with the Server object's bus allocators. abus.index simply returns the first of those indices.

When using a Bus with an In or Out UGen there is nothing to stop you from reading to or writing from a larger range, or from hardcoding to a bus that has been allocated. You are responsible for making sure that the number of channels match and that there are no conflicts. See the Server Architecture and Bus helpfiles for more information on buses and how they are used.

The hardware input busses begin just after the hardware output busses and can be read from using In.ar (See Server Architecture for more details). The number of hardware input and output busses can vary depending on your Server's options. For a convenient wrapper class which deals with this issue see SoundIn .

## Class Methods

### *kr (bus: 0, numChannels: 1)

#### Arguments:

 bus The index of the bus to read in from. numChannels The number of channels (i.e. adjacent buses) to read in. You cannot modulate this number by assigning it to an argument in a SynthDef.

## Examples

s.boot;

(
SynthDef("help-PinkNoise", { arg out=0;
Out.ar(out, PinkNoise.ar(0.1))

SynthDef("help-In", { arg out=0, in=0;
var input;
input = In.ar(in, 1);
Out.ar(out, input);

)

//play noise on the right channel
x = Synth("help-PinkNoise", [\out, 1]);

//read the input and play it out on the left channel
Synth.after(x, "help-In", [\out, 0, \in, 1]);

(
SynthDef("help-InKr",{ arg out=0, in=0;
Out.ar(out,
SinOsc.ar(In.kr(in, 1), 0, 0.1)
)
SynthDef("help-lfo", { arg out=0;
Out.kr(out, LFNoise1.kr(0.3, 200, 800))
)

b = Bus.control(s,1);
b.set(800);

Synth("help-InKr",[\in, b.index]);
b.set(400);
b.set(300);
Synth("help-lfo", [\out, b.index]);

read control data from a synth later in the node order:

(
SynthDef("help-Infreq", { arg bus;
Out.ar(0, FSinOsc.ar(In.kr(bus), 0, 0.5));

SynthDef("help-Outfreq", { arg freq = 400, bus;
Out.kr(bus, SinOsc.kr(1, 0, freq/40, freq));

b = Bus.control(s,1);
)

// add the first control Synth at the tail of the default server; no audio yet
x = Synth.tail(s, "help-Outfreq", [\bus, b.index]);

// add the sound producing Synth BEFORE it; It receives x's data from the previous cycle
y = Synth.before(x, "help-Infreq", [\bus, b.index]);

// add another control Synth before y, at the head of the server
// It now overwrites x's cycle old data before y receives it
z = Synth.head(s, "help-Outfreq", [\bus, b.index, \freq, 800]);

// get another bus
c = Bus.control(s, 1);

// now y receives x's data even though z is still there
y.set(\bus, c.index); x.set(\bus, c.index);    // WARNING! gets loud!

x.free; y.free; z.free;