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"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list