hi !

J. Scott Hildebrand wrote:

   i don't really understand how my loop creates that weird result. i

guess i just don't really get the relationship between n, in1/in2, and my arrays.

<...>

  i was told by some other PD people that the pd blocksize is

hardcoded to 64 samples and that my problem before was trying to send 256 samples at once to the soundcard. the solution that has been recommended is to place my patch as an abstraction, because the inlet/outlet will take my 256 samples and break it up into blocks pd can work with (64 samples).

do not mix things up: pd handles audio-data in blocks, which may have any size that is a power of 2. the blocksize can be controlled by the [block~] object (we had this before), and defaults to 64 samples.

only the "dac-blocksize" is hardcoded to 64 samples. This means, that you cannot have a [block~ 256] AND a [dac~] (or [adc~]) object in the same patch -- but you *can* have the [dac~] object in the "main"-patch (with a default blocksize of 64) and the [block~ 256] in a subpatch (or abstraction) inside the "main patch". How the different blocks go together should be of any concern to you, since it is managed by the [inlet~]/[outlet~] routines. If you are using an overlap of 1 (eg.: no overlap), then the stream of samples will be continously, eg: it doesn't make a difference when you look at the signal with pe a [scope~] object. if there is an overlap defined, this is not true any longer, since the overlapping part of the signal will appear in subsequent blocks.

now what is "n" (which is sp[0]->s_n) ? n is the blocksize. so normally "n" will just be 64, however if you have used [block~ 256] in an abstraction, "n" will be 256 for all of the signal-objects inside this abstraction (and all sublevels except those overriden by another [block~])

now what is "in1" (resp. "in2") (which is sp[0]->s_vec) ? "in1" is a pointer to an array of "n" (see above") samples.

so you will get the current block of the audio-signal only with both "n" and "in1"

confusion: "in1" might point to the same memory-area as "out1", so be careful when writing things to the out-buffer ("out1") before having read the in-buffer ("in1") if you want to process the in-buffer somehow, for the data might be overwritten/lost

...

here starts the trouble

...

for(readpos=0; readpos<64; readpos++)

you should never hardcode the blocksize 64 into your external, since it just might be wrong !

  i have looked at a few externals but i couldn't find any useful

information. i'm trying to basically work on the DSP stuff right now but i have a barely working convolver in my code right now. everything has been uber simplified so if you could take a look it wouldn't take you more than a minute or two. and if you have any external or a piece of code that i might be able to learn something from, please send it my way! thanks!

please DO NOT start with a convolver !

please DO start with the pd-externals-HOWTO @ http://pd.iem.at/externals-HOWTO/

do not use variables declared "static" as long as they are not absolutely necessary (in most cases they are not)

do start with the simplest possible external (reading from input, writing to output), and make it work then gradually increase the complexity (buffering; stereo; etc) of the external and check and double-check whether it still works (and if not, try to find the error. you can use debugging output to the console!)

in *your* special case, read about OLA (overlap-and-add) and block-filtering-techniques, and see that pd is ideal for this kind of things.

mfg.cds.adr IOhannes

PS: damned: can you tell me, which values your variable "apple" will have between starting the audio-engine and the segfault ?