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