[CM] tap and comb pm arguments

[cristopher pierson ewing]

Bill,

Thanks for the quick reply.

As to the name-space issue, I'm pretty sure that's not the problem.  As
long as I only write (setf tap (tap d)) there is no problem.  The second
channel shows up just as might be expected.  It is only when I try to
supply a second arg (the &optional offset) that the channel disppears.
But there is no warning of using an argument that is illegal.  Only when
adding the erroneous pm arg does an error message occur.  It reports that
tap expects between 1 and 2 args.  I don't know enough about clm error
reporting to suggest from where this might be cropping up.  I can only
report the results I have gotten.  If it would be helpful to you, I can
provide listener output resulting from specific calls to the instruments I
have tested, and even example soundfiles, if needed.


Thanks also for the explanation re. frequency vs. sample differences in
the comb pm arg.  It's amazing how quickly one's powers of mathematical
reasoning disappear when you've been coding for too many hours straight.

Happy day!

C

********************************
Cris Ewing
CARTAH Assistant
University of Washington
Home Phone: (206) 365-3413
E-mail: cewing@u.washington.edu
*******************************


On Fri, 14 Feb 2003, Bill Schottstaedt wrote:

> 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).
>