[PD-dev] Re: writing externals (J. Scott Hildebrand....)

[IOhannes zmoelnig]

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 ?