pland

Had mail server crash and missed Peter's reply...(thanks though, peter)

> With poly~ you can specify the vector size specific to the instance of

> poly~ using vs 16384 as an argument to poly~.

Using [poly~ mypatch 1 vs 16384] gives me:

error: poly~ bad fixed vector size and/or sample-rate (16384 > 64)

Is it that poly~ itself thinks it vs 64? Can't quite get the conflict...

> From: Peter McCulloch 
> Date: 03/13/07
> Message-Id: 
> With poly~ you can specify the vector size specific to the instance of
> poly~ using vs 16384 as an argument to poly~.
>

--
David Plans Casal
Digital Technologist
School of Arts
Brunel University

e  : david dot plans at brunel.ac.uk
t   : +44 1895 266 475
m : +44 7803 173 959

block-equivalent-2

Whoops, bad assumption on my part. It looks like poly~ will not accept 

a vs greater than the current vector size, set in the max dsp window.

Unfortunately, it looks like fft~'s maximum block size is 4096. 

Probably the best solution would be to strip out the fft analysis code 

from the input of your object, and use the native pfft~ analysis, which 

supports a framesize of 16384 and overlap of 8, as input to your 

On Mar 15, 2007, at 8:34 AM, David Plans Casal wrote:

> Had mail server crash and missed Peter's reply...(thanks though, peter)

>> With poly~ you can specify the vector size specific to the instance of

>> poly~ using vs 16384 as an argument to poly~.

> Using [poly~ mypatch 1 vs 16384] gives me:

> error: poly~ bad fixed vector size and/or sample-rate (16384 > 64)

> Is it that poly~ itself thinks it vs 64? Can't quite get the 

Whoops, bad assumption on my part.  It looks like poly~ will not accept 
a vs greater than the current vector size, set in the max dsp window.

Unfortunately, it looks like fft~'s maximum block size is 4096.  
Probably the best solution would be to strip out the fft analysis code 
from the input of your object, and use the native pfft~ analysis, which 
supports a framesize of 16384 and overlap of 8, as input to your 
object.

> Hello,
>
> Had mail server crash and missed Peter's reply...(thanks though, peter)
>
>
>> From: Peter McCulloch 
>> Date: 03/13/07
>> Message-Id: 
>> With poly~ you can specify the vector size specific to the instance of
>> poly~ using vs 16384 as an argument to poly~.
>>
>
> Using [poly~ mypatch 1 vs 16384] gives me:
>
> error: poly~ bad fixed vector size and/or sample-rate (16384 > 64)
>
> Is it that poly~ itself thinks it vs 64? Can't quite get the 
> conflict...
>
> d
>
> --
> David Plans Casal
> Digital Technologist
> School of Arts
> Brunel University
>
> e  : david dot plans at brunel.ac.uk
> t   : +44 1895 266 475
> m : +44 7803 173 959
>
>
>
>
www.petermcculloch.com


On 15 Mar 2007, at 16:34, Peter McCulloch wrote:

> Whoops, bad assumption on my part. It looks like poly~ will not 

> accept a vs greater than the current vector size, set in the max 

> Unfortunately, it looks like fft~'s maximum block size is 4096. 

> Probably the best solution would be to strip out the fft analysis 

> code from the input of your object, and use the native pfft~ 

> analysis, which supports a framesize of 16384 and overlap of 8, as 

> Whoops, bad assumption on my part.  It looks like poly~ will not  
> accept a vs greater than the current vector size, set in the max  
> dsp window.
>
> Unfortunately, it looks like fft~'s maximum block size is 4096.   
> Probably the best solution would be to strip out the fft analysis  
> code from the input of your object, and use the native pfft~  
> analysis, which supports a framesize of 16384 and overlap of 8, as  
> input to your object.

block~ equivalent?