J. Scott Hildebrand wrote:
i'll just copy and paste my short code which does convolution. it'snot 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