stereo/multi-channel fft hooha

Mar 14, 2007 at 6:34pm

stereo/multi-channel fft hooha

hi maxlist

i’m in the process of educating myself of educating myself about all
things fft in max-msp (primarily through richard dudas and cort
lippe’s excellent phase vocoder tutorial) and i’m wondering this:
what’s happening when my buffer~ contains stereo or multi-channel
sound? the output in all the examples i’ve seen is mono, so is there
summing that occurs or is only one channel used?

thanks!
jesse

#30822
Mar 14, 2007 at 8:50pm

i just answered my own question by creating a stereo test tone and
running it through the dudas/lippe phase vocoder patch. only the
first channel of the buffer is used, the others are ignored.

On Mar 14, 2007, at 2:34 PM, jesse stiles wrote:

> hi maxlist
>
> i’m in the process of educating myself of educating myself about
> all things fft in max-msp (primarily through richard dudas and cort
> lippe’s excellent phase vocoder tutorial) and i’m wondering this:
> what’s happening when my buffer~ contains stereo or multi-channel
> sound? the output in all the examples i’ve seen is mono, so is
> there summing that occurs or is only one channel used?
>
> thanks!
> jesse

#99163

Anonymous

Anonymous
Mar 15, 2007 at 9:50am

Hi Jesse,

looking in the doc or help file from buffer~ object you will find:
it is necessary to set the number of channels as argument. One
channel is default.

Best,

Juergen

Am 14.03.2007 um 21:50 schrieb jesse stiles:

> i just answered my own question by creating a stereo test tone and
> running it through the dudas/lippe phase vocoder patch. only the
> first channel of the buffer is used, the others are ignored.
>
> On Mar 14, 2007, at 2:34 PM, jesse stiles wrote:
>
>> hi maxlist
>>
>> i’m in the process of educating myself of educating myself about
>> all things fft in max-msp (primarily through richard dudas and
>> cort lippe’s excellent phase vocoder tutorial) and i’m wondering
>> this: what’s happening when my buffer~ contains stereo or multi-
>> channel sound? the output in all the examples i’ve seen is mono,
>> so is there summing that occurs or is only one channel used?
>>
>> thanks!
>> jesse
>

#99164
Apr 24, 2007 at 6:16pm

hello maxlist,

i’m writing to report a bizarre DSP malfunction i’ve encountered with
one of my patches: the patch will perform normally for a period of
time (ranging from 2 seconds to 45 minutes) but then signal
processing will mysteriously stop in certain parts of the patch while
DSP in other areas of the patch continues to function normally.

where exactly the break in signal processing occurs changes every
time. by attaching number~’s to many different parts of the signal
chain i’ve determined what happens at the place where the break
occurs: the “broken” MSP object is given a normal signal as input
and produces “nan” (“not a number”) as output. i’ve reproduced the
malfunction at many different parts of the signal chain and there
doesn’t seem to be any pattern as to what object “breaks.”

the patch can be induced to resume total normal functioning by either
switching adstatus off and on or by creating/deleting a new MSP
object/connection (while keeping adstatus on). this “fixes” the
patch no matter which object in the signal change has “broken” and is
outputting “nan” despite normal input.

i should also note that the malfunction seems to disable the audio
output device for all applications: the finder, quicktime, etc. once
the patch is “fixed”, all applications are once again able to access
the audio device.

i can’t determine any causality for the error. the patch will break
itself without any user input, and will do so after a seemingly
random period of time, usually greater than 20 minutes and less than
an hour.

i’ve reproduced the malfunction using the same patch on multiple
computers (mac mini G4 and a powerbook G4), with multiple audio
devices (built-in audio and a MOTU Traveler), and on both Max/MSP 4.5
and 4.6. all other patches function perfectly using the same
computers, sound devices, and max/msp installations.

has anyone every seen anything like this or have any advice as to how
i can address this? the patch is a complex long-term project so i’m
quite invested in getting it running normally.

many thanks,
jesse

#99165
Apr 24, 2007 at 6:44pm

On 24 avr. 07, at 20:16, jesse stiles wrote:

> hello maxlist,
>
> i’m writing to report a bizarre DSP malfunction i’ve encountered
> with one of my patches: the patch will perform normally for a
> period of time (ranging from 2 seconds to 45 minutes) but then
> signal processing will mysteriously stop in certain parts of the
> patch while DSP in other areas of the patch continues to function
> normally.
>
> where exactly the break in signal processing occurs changes every
> time. by attaching number~’s to many different parts of the signal
> chain i’ve determined what happens at the place where the break
> occurs: the “broken” MSP object is given a normal signal as input
> and produces “nan” (“not a number”) as output. i’ve reproduced the
> malfunction at many different parts of the signal chain and there
> doesn’t seem to be any pattern as to what object “breaks.”
>
> the patch can be induced to resume total normal functioning by
> either switching adstatus off and on or by creating/deleting a new
> MSP object/connection (while keeping adstatus on). this “fixes”
> the patch no matter which object in the signal change has “broken”
> and is outputting “nan” despite normal input.
>
> i should also note that the malfunction seems to disable the audio
> output device for all applications: the finder, quicktime, etc.
> once the patch is “fixed”, all applications are once again able to
> access the audio device.
>
> i can’t determine any causality for the error. the patch will
> break itself without any user input, and will do so after a
> seemingly random period of time, usually greater than 20 minutes
> and less than an hour.
>
> i’ve reproduced the malfunction using the same patch on multiple
> computers (mac mini G4 and a powerbook G4), with multiple audio
> devices (built-in audio and a MOTU Traveler), and on both Max/MSP
> 4.5 and 4.6. all other patches function perfectly using the same
> computers, sound devices, and max/msp installations.
>
> has anyone every seen anything like this or have any advice as to
> how i can address this? the patch is a complex long-term project
> so i’m quite invested in getting it running normally.

There’s not enough information for us to investigate. Can you post a
patch or part of?

Thanks,
ej

#99166
Apr 24, 2007 at 10:47pm

it is a normal behaviour for a hardware driver that it drop
out or even chrashes when it recieves what you called NaN.

it is not the exspected behaviour of a maxmsp object to output
such denormal signals.

try to find out which object or code is originalla producing
that.

#99167
Apr 25, 2007 at 5:33am

nan or not a number is the result of not a calculation, or one that is not allowed; for instance -1 to the power of 0.5. This does not normally ‘break’ an objects fucntioning, unless there is some kind of feedback in the object, meaning that the nan will continu to be part of a then unsolvable calculation. Look at the bitsafe~ helpfile for more info. Anyhow, somewhere in the patch an calculation that is not allowed is (not) being performed.

_
johan

#99168
Apr 25, 2007 at 3:35pm

thanks johan, roman, & emmanuel for your responses.

i’ve tried to isolate the point in the signal chain where the
unacceptable calculation is occurring without success. it seems to
occur at a different point in the chain every time – sometimes at a
point where no calculation is actually being performed!

for example, it might happen between a send~ and a receive~ : a
number~ receiving the same input as the send~ will show a normal
signal and a number~ receiving what should be the same signal from
the receive~ shows “Nan.” which makes wonder if the problem is
actually in the structure of the patch…

the patch is a little complex but i’m working on a simplified
debugging version of it which i can put online if anyone’s interested.

thanks for your support!
jesse

On Apr 25, 2007, at 1:33 AM, jvkr wrote:

>
> nan or not a number is the result of not a calculation, or one that
> is not allowed; for instance -1 to the power of 0.5. This does not
> normally ‘break’ an objects fucntioning, unless there is some kind
> of feedback in the object, meaning that the nan will continu to be
> part of a then unsolvable calculation. Look at the bitsafe~
> helpfile for more info. Anyhow, somewhere in the patch an
> calculation that is not allowed is (not) being performed.
>
> _
> johan

#99169

You must be logged in to reply to this topic.