[PD] bad vector size

[IOhannes zmoelnig]

J. Scott Hildebrand wrote:
>        i'll just copy and paste my short code which does convolution. it's
> not in realtime but right now i'm trying to just get it to spit out audio.
> this is the error i get:
> 
> error: dac~: bad vector size
> error: dac~: bad vector size
> Segmentation fault

hi !
no my 1% to the [block~] discussion.
the dac~ blocksize is hardcoded (!) to 64 samples.
thus you must not place a [block~] object (other than [block~ 64]) into 
the patch containing adc~/dac~s.
You will have to put the routines that need other (bigger) block-sizes 
into a sub-patch. it doesn't matter, whether you use ordinary-subpatches 
([pd ...]) or abstractions (*.pd files).

and now some other features of [block~] (to complicate things a little 
bit, but with no direct relationship to your problems)
[block~] and [switch~] are more-or-less the same object.
The difference is only, that [switch~] uses its inlet ([block~] does 
not, the inlet is for historic(?) reasons only).
if you send a "0" to the [switch~] it will turn the audio-engine in its 
patch and in all of its child-patches off.
you can reenable the (local+all children's) dsp-calculations with a "1".
both objects eat 3 (optional) arguments, the 2 (by now hopefully) known 
"block-size" and "overlap-factor", and a 3rd "upsampling-factor" that 
allows you to up/down-sample the signal in a sub-patch (again: not the 
(root-)patch that contains the [dac~]/[adc~] !)
if given, all of these arguments have to be powers of 2, thus a 
blocksize of "200" will not work, and you cannot overlap by 1/3rds or do 
a downsampling by the factor 10.
While blocksize and overlap have to be greater 1 (which makes sense), 
the upsampling factor can also be less than 1 to allow downsampling - 
like 2^(-2) for downsampling from 44.1kHz to 11.025kHz)

to avoid confusion, you might to want to forget the last paragraph, and 
reread it later...


mfg.c.asdr
IOhannes