b = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01.wav");
{ BufRd.ar(1, b, SinOsc.ar(0.1) * BufFrames.ir(b),loop: 0.0) }.play;
{ BufRd.ar(1, b, LFSaw.ar(BufDur.ir(b).reciprocal).range(0, BufFrames.ir(b)), 0 ) }.play;
{ BufRd.ar(1, b, Phasor.ar(0, BufRateScale.kr(b), 0, BufFrames.kr(b)), 0.0) }.play;
The loop argument is not working when set at 0 or 0.0.
Hi @fmiramar , i think you're misunderstanding the purpose of this parameter. it controls whether the phase parameter will be wrapped within the valid index range [0, nFrames). so, in your first example:
{ BufRd.ar(1, b, SinOsc.ar(0.1) * BufFrames.ir(b),loop: 0.0) }.play;
when the output of SinOsc becomes negative, phase drops below 0 and because loop is set to 0, the output is silent. when you set loop to 1 instead, the negative part of SinOsc's cycle produces output again. the reason for the name loop, i think, is that in contexts where the input is an indefinitely growing value, the UGen will indeed appear to be looping the buffer.
if you think the documentation is inaccurate, please feel free to submit a pull request!
Also (and this is important): both Phasor and LFSaw inherently loop over a numeric range. loop can affect BufRd's behavior but it can't stop other inherently looping UGens from looping.
So this is definitely not a bug. If you don't want it to loop, don't use Phasor or LFSaw here.
Sorry for the mistake and thanks for the explanation! I think BufRd documentation should definitively be improved, especially if it can include an example the usage of the loop argument. I will submit a pull request ASAP.
The best way IMO to demonstrate the loop argument's effect is to drive BufRd with a Line.ar, going beyond the buffer size.