[PD] downsampling ??? (again)

[IOhannes m zmoelnig]

hi miller:
Miller Puckette wrote:
> 
> Hi Iohannes,
> 
> It's indeed a good idea...  I haven't had time to think about how to make
> it general enough (busy with bug fixes, and now with ICMC prep...)

hope it was fun in cuba (at least, wini said so...)

two or more thoughts about the up/down-issue (again):

1.)
> 
> I'd suggest using true powers of two (4, 0.125. etc) to indicate how much
> to sample up or down.
i agree with the "true powers of 2" indicating up/downsampling-factor,
but i am not sure, which one to take for up- and which one for
down-sampling.
currently my patch gets a downsampling-rate (2 runs at half the
sample-rate), though this would better be upsampling ???
on the other hand, i suppose people are more willing to downsample than
to upsample and maybe integer-values are easier to read/write ?
would be great if we could come to some consensus, before people start
to use a version that is very likely to change...
(up till now, i think there is only one user that has written patches
that depend on the downsampling-thing.
but nevertheless we should decide on this soon...)

2.)
> Anyway, it would be best to have a range of algorithms (although
> perhaps not an easy task to realize...)
should the algorithm-selection be a matter of patch (and therefore be
defined via the block~) or a matter of inlet~/outlet~ ?
wini meant, you would need some more thinking about this ??
the only problem i see with in/outlet~s providing different
up/downsampling algorithms, is that due to these algorithms we will
eventually get various delays (just because sample'n'hold needs no
delay, whereas a sinc-interpolation would (ideally) need
infinite delay).
should inlets (or outlets) should be "in phase" or should they just be
"as fast as possible" ?

3.)
> I'm not sure how this will interact with blocking and
> overlap.  Anyway, it would be best to have a range of algorithms (although
> perhaps not an easy task to realize...)

btw: (bug !)
the overlap&add does not work correctly for "block~ 64 2" and the like
(if an overlap factor other than 1 is defined, then vecsize/overlap has
to be > 64 for correct OLA!!!)
if you cascade to subpatches, the first with "block~ 32 1" and the
inner-one with "block~ 64 2" you do not get this problem.

indeed, i have problems with simultanously upsampling and overlapping.
cascading into an outer patch that does the downsampling and an inner
patch that does the OLA works, though (so i think this refers to the bug
(s.a.))

mfg.asdf.cas
IOhannes

> 
> cheers
> Miller
> 


> >