[Pd] Complex audio signals

Chuckk Hubbard badmuthahubbard at gmail.com
Tue Jun 20 15:49:46 CEST 2006


On 6/20/06, Piotr Majdak <piotr at majdak.com> wrote:
> Chuckk Hubbard wrote:
> > On 6/20/06, Chuckk Hubbard <badmuthahubbard at gmail.com> wrote:
> >
> >> On 6/20/06, Piotr Majdak <piotr at majdak.com> wrote:
> >> > > Another question: if I just ran rfft~ on a signal, and then ran ifft~
> >> > > on the transform, would that create the same signal as a complex
> >> > > signal?
> >> >
> >> > Using [rfft~] you can process real signals only...
> >>
> >> I meant like:
> >> [readsf~] (for instance)
> >> |
> >> [rfft~]
> >> |      |
> >> [ifft~]  [num\ [num\
> >> |   |     |         |
> >> [czero~]
> >> |
> >> [dac~]
> >>
> >> I suppose I could just try it and see if it works...
>
> You transform the signal from [readsf~] to the frequency domain (it's complex
> now), then transform it back to the time domain (now it's real again and
> identical to the signal from [readsf~]). Why do you do that?

The inverse transform is complex, from a real forward transform.  I'm
just trying to find out what the imaginary part should be.

>
> According to the help patch, [czero~] does: y[n] = x[n] - a[n] * x[n-1].
> To get a consistent filtering with [czero~] the imaginary part of the result
> should be zero (the real part can be the input for [dac~], as you did it), which
> means, that a[n] must be conj(x[n]), or in this case the imag(a)=0. Of course,
> you can use a chain of [czero~]s, where the intermediate results are complex.
> However, after the last [czero~], the result should be real.
>
> To play with [czero~], try the [pd test] subpatch in the help file of [czero~].

If I understand you correctly, this is similar to what Miller's book
talks about.  Pairing every complex filter with another with the
conjugate of its coefficient, so that the real signal can be treated
as the sum of two complex signals which are conjugates of each other.
Hallelujah, I just made it work.  Not so hard.  Far easier than trying
to make a real signal complex.

>
> > It doesn't.  Nor does:
> > [osc~]
> > |
> > [rfft~] [sig~ 0]
> > |        |
> > [ifft~]
> >
>
> Can you tell me, what are you trying to do? You know, this patch works (no
> errors), but I don't know how to interpret the resulting signals...

Writing the original signal and the real and imaginary parts of the
output to graphs shows lots of alterations.  It is fine with a block
containing an integer number of cycles, but otherwise gets weird
results.  See attached.

-Chuckk
-------------- next part --------------
#N canvas 0 0 1032 771 12;
#N canvas 0 0 450 300 graph4 0;
#X array real 64 float 3;
#A 0 0.999999 0.995183 0.980783 0.956938 0.923877 0.881919 0.831467
0.773008 0.707104 0.634391 0.555568 0.471394 0.382681 0.290282 0.195088
0.098015 -2.08616e-006 -0.0980191 -0.195092 -0.290286 -0.382685 -0.471398
-0.555571 -0.634394 -0.707108 -0.773011 -0.83147 -0.881922 -0.92388
-0.956941 -0.980786 -0.995185 -1 -0.995185 -0.980786 -0.956941 -0.92388
-0.881922 -0.83147 -0.773011 -0.707108 -0.634394 -0.555571 -0.471398
-0.382685 -0.290286 -0.195092 -0.0980191 -2.08616e-006 0.098015 0.195088
0.290282 0.382681 0.471394 0.555568 0.634391 0.707104 0.773008 0.831467
0.881919 0.923877 0.956938 0.980783 0.995183;
#X coords 0 1 63 -1 200 140 1;
#X restore 28 367 graph;
#N canvas 0 0 450 300 graph5 0;
#X array imag 64 float 3;
#A 0 0 0.0980175 0.195091 0.290285 0.382684 0.471397 0.55557 0.634393
0.707107 0.77301 0.831469 0.881921 0.923879 0.956939 0.980784 0.995184
0.999999 0.995184 0.980784 0.956939 0.923878 0.88192 0.831468 0.773009
0.707106 0.634392 0.555569 0.471396 0.382683 0.290284 0.19509 0.098017
0 -0.098017 -0.19509 -0.290284 -0.382683 -0.471396 -0.555569 -0.634392
-0.707106 -0.773009 -0.831468 -0.88192 -0.923878 -0.956939 -0.980784
-0.995184 -0.999999 -0.995184 -0.980784 -0.956939 -0.923879 -0.881921
-0.831469 -0.77301 -0.707107 -0.634393 -0.55557 -0.471397 -0.382684
-0.290285 -0.195091 -0.0980175;
#X coords 0 1 63 -1 200 140 1;
#X restore 36 563 graph;
#N canvas 0 0 450 300 graph5 0;
#X array orig 64 float 3;
#A 0 0.999999 0.995194 0.980804 0.956969 0.923917 0.881968 0.831525
0.773073 0.707177 0.63447 0.555653 0.471485 0.382776 0.290381 0.195189
0.0981172 0.000100675 -0.0979168 -0.194991 -0.290188 -0.38259 -0.471307
-0.555486 -0.634315 -0.707035 -0.772946 -0.831413 -0.881873 -0.92384
-0.95691 -0.980765 -0.995174 -0.999999 -0.995194 -0.980805 -0.956969
-0.923918 -0.881969 -0.831526 -0.773075 -0.707179 -0.634472 -0.555655
-0.471487 -0.382778 -0.290383 -0.195191 -0.0981197 -0.000103244 0.0979142
0.194989 0.290185 0.382587 0.471305 0.555484 0.634313 0.707033 0.772944
0.831411 0.881872 0.923839 0.956909 0.980764 0.995174;
#X coords 0 1 63 -1 200 140 1;
#X restore 42 152 graph;
#X msg 424 229 bang;
#X obj 690 170 rfft~;
#X obj 690 199 ifft~;
#X obj 686 82 osc~;
#X floatatom 686 51 5 0 0 0 - - -;
#X msg 764 105 0;
#X obj 893 269 -~;
#X obj 917 324 env~;
#X floatatom 925 353 5 0 0 0 - - -;
#X obj 747 167 sig~ 0;
#X obj 690 141 /~ 32;
#X obj 514 317 tabwrite~ real;
#X obj 597 367 tabwrite~ imag;
#X obj 638 436 tabwrite~ orig;
#X connect 3 0 14 0;
#X connect 3 0 15 0;
#X connect 3 0 16 0;
#X connect 4 0 5 0;
#X connect 5 0 9 0;
#X connect 5 0 14 0;
#X connect 5 1 15 0;
#X connect 6 0 9 1;
#X connect 6 0 13 0;
#X connect 6 0 16 0;
#X connect 7 0 6 0;
#X connect 8 0 6 1;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 12 0 5 1;
#X connect 13 0 4 0;


More information about the Pd-list mailing list