One small warning - the output of samplerate~ is confusing if there is overlap - samplerate~ output goes up by the overlap factor, which is arguably incorrect. It needs replacing by a more comprehensive solution.
Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it "correct' or just leave it wrong. The throw~/catch~ 64-sample restriction is fixable. It would be a much bigger project to make them work across arbitrary changes of sample rate, block size, and overlap. cheers Miller On Mon, Oct 20, 2008 at 02:57:57PM +0200, Derek Holzer wrote: > Hi David, > > try putting [samplerate~] in each subpatch or abstraction to see if the > changes by [block~] are passed down. I don't know offhand if they are, > but I *think* that is correct. > > best, > d. > > David F. Place wrote: > > > This is confusing to me. If the overlap and resampling ratio are > > relative to the super-patch, then shouldn't block~ set the block size, > > overlap, and up/down-sampling ratio for the window and all its sub > > windows? (sub-patches and abstractions) Is that how it works, in fact? > > > -- > derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista > ---Oblique Strategy # 142: > "Shut the door and listen from outside" > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
