larme

Is it possible to access a sample point in a 

 object without interpolation? The use case is that I want to use the data in 

 as parameters instead of audio waveforms, so I want to get the exact sample at certain index.

Attached is a test example I construct. It seems that

output) will interpolate, which is not what I want.

testpoly.zip

Is it possible to access a sample point in a [buffer~] from a [gen~] object inside a oversampling [poly~] object without interpolation? The use case is that I want to use the data in [buffer~] as parameters instead of audio waveforms, so I want to get the exact sample at certain index. 

Attached is a test example I construct. It seems that [index~] inside a [poly~] will not interpolate (the first [poly~] output in the example) but [peek @interp none] (the second [poly~] output) will interpolate, which is not what I want.

Hi all,
Is it possible to access a sample point in a [buffer~] from a [gen~] object inside a oversampling [poly~] object without interpolati

question-about-«gen~»-object-accessing-a-buffer-inside-a-oversampling-«poly~»

Weird. I played around with this, and found two different workarounds, neither of which made immediate sense:

1) Use @interp linear, but put [+ 0.5]->[floor] to the index just before the [peek].

2) send in the sample index via send~ / receive~ instead of in~ 1

I did notice that a number~ *inside* the poly patcher sometimes shows the gen~ output as off by exactly zero or one samples; but the number~ *outside* the poly patcher seems to be much less regular (as if interpolated, as you say). This reminded me that signals going into and out of an upsampled poly will also be subject to some filters and averaging. So I guess of the 8 upsamples, some are outputing one result, some are outputting another, and filtered together they make an unexpected value. That would explain why using receive~ doesn't show the odd behaviour.

I also noticed that if you nudge the sample index slightly off an integer value, this irregularity disappears. So my guess is that there's some very small floating point error creeping in with the oversampling that is somehow throwing off the index computation slightly (i.e. the rounding of float signals to integer buffer samples).

I also notice that MSP's [index~] rounds differently to gen~'s [peek @interp none], i.e. an index of 1.5 will return sample 2, whereas gen~'s [peek @interp none] will return sample 1. This might have something to do with why the weirdness doesn't show up with index~ -- indeed if you set the sample index to be 41.5, the index~ in the poly~ now outputs irregular values. (So this is definitely not a gen~ issue :-))

1) Use @interp linear, but put [+ 0.5]->[floor] to the index just before the [peek]. 

I did notice that a number~ *inside* the poly patcher sometimes shows the gen~ output as off by exactly zero or one samples; but the number~ *outside* the poly patcher seems to be much less regular (as if interpolated, as you say). This reminded me that signals going into and out of an upsampled poly will also be subject to some filters and averaging. So I guess of the 8 upsamples, some are outputing one result, some are outputting another, and filtered together they make an unexpected value.  That would explain why using receive~ doesn't show the odd behaviour.  

I also noticed that if you nudge the sample index slightly off an integer value, this irregularity disappears. So my guess is that there's some very small floating point error creeping in with the oversampling that is somehow throwing off the index computation slightly (i.e. the rounding of float signals to integer buffer samples). 

question about [gen~] object accessing a buffer inside a oversampling [poly~]