• Index_next_k() accesses index ZIN0(1) once per control cycle -- i.e., assumes a kr index.
• Index_next_a() accesses index ZIN0(1) inNumSamples times per control cycle -- ar index.

Both calculation functions do GET_TABLE only once per control cycle -- so the bufnum input does not support ar under any circumstances.

But, the Ctor chooses next_k for a control-rate bufnum, regardless of the rate of the input that matters (index). So this PR changes INRATE(0) to INRATE(1).

Five other UGens follow the same pattern: IndexL, FoldIndex, WrapIndex, IndexInBetween and DetectIndex.

Test: without the fix, the following displays an obvious sample-and-hold. With the fix, Index.ar is correctly equivalent to BufRd.ar without interpolation.

(
s.waitForBoot {
	b = Buffer.alloc(s, 512, 1, completionMessage: { |buf|
		buf.sine3Msg([4], [1], [0.25pi], asWavetable: false)
	});
	s.sync;
	{
		var phase = Phasor.ar(0, 1, 0, 1000);
		[Index.ar(b, phase), BufRd.ar(1, b, phase, interpolation: 1)]
	}.plot(duration: b.duration); 
};
)

I'll suggest 3.9.1 for this as it's a small bugfix.