[PD] Scope of [block~] and [switch~]

[Miller Puckette]

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