[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/