[CM] tap and comb pm arguments

[Bill Schottstaedt]

Thanks for the bug reports!

> And if I try to give a third argument to tap, the
> ;;&optional pm, it complains that tap expects between 1 and 2 arguments.

That's an error in the documentation -- tap doesn't take a third argument.

> ;;by my reading, the p.m. argument to comb should work as an additive
> ;;value to the index into the delay.  I would expect then, that given
> ;;a ringing frequency of 400 hz (or del-time = (/ 1.0 400)), and a f-dif
> ;;value of 200, I would get a result where the left channel rings at 400
> ;;hz and the right rings at 600.  Instead, I get the left at 400 and the
> ;;right at 133.333..

It's additive in the sense of delay length, not the resultant frequency.
So, given your numbers, and taking srate=22050, 400Hz = delay of 55 samples,
add 200 via (/ 22050 200) = 110 giving a total delay of 165 = freq peak at 133.
To get a tap peak at a given frequency given the original at f-dif, you need
to get the difference between the length for f-dif and the length for the new frequency:

         (s-dif (- (seconds->samples (/ 1.0 f-dif)) samples))

or something like that.

> ;;No matter what values i give for tap-offset, the right channel has
> ;;nothing in it at all.

I don't think the CL version of the run macro tries to implement CL's
multiple name spaces in the sense that you can have a variable and
a function with the same name.  I'd use "tap1" for the variable name --
I'll look into an error message for this.  But, there does seem to
be a bug in tap if the max-size arg is given to the associated delay.
I don't immediately see the problem (the parallel Scheme code appears
to work ok).