[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sc-users] Re: Index.ar vs BufRd.ar



i wrote
> {
> 	l = LFSaw.ar(d.duration.reciprocal).range(0,d.sampleRate * d.duration);
> 	[
> 		Index.ar(d, l),
> 		BufRd.ar(1, d, l, 0, 1)
> 	]
> }.plot

It's a bug.

In OscUGens.cpp, Index *does* have an _a rate and a _k rate "next" function.
The _a rate function is supposed to read the index (input 1) for every
sample.

BUT... _a or _k is chosen based on input 0 -- the buffer number. This makes
no sense.

Quick test: if I do DC.ar(b.bufnum) instead of b, it works -- audio-rate
indexing.

s.boot;

b = Buffer.alloc(s, 512, 1, completionMessage: { |buf| buf.sine3Msg([4],
[1], [0.25pi], asWavetable: false) });

{
	var phase = Phasor.ar(0, 1, 0, 1000);
	[Index.ar(b, phase), Index.ar(DC.ar(b.bufnum), phase)]
}.plot(duration: b.duration);

So this is the problem:

	} else if (INRATE(0) == calc_FullRate) {
		SETCALC(Index_next_a);
	} else {
		SETCALC(Index_next_k);
	}

... should be INRATE(1).

Jeez. How many years has it been like this?

hjh



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/