jts3k

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?

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?

stereomulti-channel-fft-hooha

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:

> 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?

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.

> 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


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 

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:

>> 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?

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.

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


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 

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 

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 

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.

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.

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

> 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 

> 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 

> 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 

> 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 

> 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?

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

try to find out which object or code is originalla producing

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.


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.

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.

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

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.

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


stereo/multi-channel fft hooha