Luigi Castelli

what I am trying to accomplish is something really simple, that - for

some reason - is giving me a hard time. I want to get the highest audio

sample value between two scheduler intervals. I want the output as a

regular float, so even though I read audio at the sampling rate I will

I have a perform loop that looks something like:

Also, I have a clock that calls my bang method every N ms.

For some reason I don't get the expected result. Many times my output

is just 0. I compared this with peakamp~ and it works fine there. How

is it done ? What am I missing here ? It seems such a simple task to

accomplish, yet I am doing something incorrectly.

------------------------------------------------------------

THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.

Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.

http://answers.yahoo.com/dir/?link=list&sid=396545469

what I am trying to accomplish is something really simple, that - for
some reason - is giving me a hard time. I want to get the highest audio
sample value between two scheduler intervals. I want the output as a
regular float, so even though I read audio at the sampling rate I will
output values at the scheduler rate.

    if (zin > x->maxamp) {
        x->maxamp = zin;
    }
}

Also, I have a clock that calls my bang method every N ms.
The bang method is defined as:

void myobj_bang(t_myobj *x)
{
    outlet_float(x->out, x->maxamp);
    x->maxamp = 0.;
}

For some reason I don't get the expected result. Many times my output
is just 0. I compared this with peakamp~ and it works fine there. How
is it done ? What am I missing here ? It seems such a simple task to
accomplish, yet I am doing something incorrectly.

------------------------------------------------------------
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
------------------------------------------------------------

Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469


simulating-peakamp-behavior

I'm wondering if you've hit some float/double ambiguity in the C syntax of your compiler. I generally declare all non-array usage of floating point variables as doubles. Maybe try something like:

double zin = *in++; // unambiguous typecast

And make sure your maxamp component is also declared double.

Using double-precision is typically more efficient than single-precision anyway.

This is a wild guess, but let us know if it helps

double zin = *in++; // unambiguous typecast
double abszin = fabs(zin);

if (abszin > x->maxamp) {
x->maxamp = abszin;
}
}

This is a wild guess, but let us know if it helps


No, the problem persists and it is really weird.

So I compiled a custom peakamp~ object just to show what's happening...

Attached is my w.peakamp~ object, its help file, and the code I wrote

Try opening the help file and setting the metro object with an interval

of 20ms. Also set your vector size to 1024.

It seems that every 20 ms or so my peakamp~ object outputs a zero

The only explanation I could find is that some thread locking mechanism

is kicking in and preventing my variables from being updated.

However, it doesn't happen with the standard distribution peakamp~.

I am working on an object that needs to implement the peakamp~

functionality on top of other stuff and I cannot proceed forward until

> I'm wondering if you've hit some float/double ambiguity in the C

> syntax of your compiler. I generally declare all non-array usage of

> floating point variables as doubles. Maybe try something like:

> double zin = *in++; // unambiguous typecast

> And make sure your maxamp component is also declared double.

> Using double-precision is typically more efficient than

> This is a wild guess, but let us know if it helps

> Peter Castine +--> Litter Power & Litter Bundle for

> iCE: Sequencing, Recording & Interface Building for Max/MSP 

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.

So I compiled a custom peakamp~ object just to show what's happening...
Attached is my w.peakamp~ object, its help file, and the code I wrote
to generate the object.
Try opening the help file and setting the metro object with an interval
of 20ms. Also set your vector size to 1024.

It seems that every 20 ms or so my peakamp~ object outputs a zero
value.
The only explanation I could find is that some thread locking mechanism
is kicking in and preventing my variables from being updated.

I am working on an object that needs to implement the peakamp~
functionality on top of other stuff and I cannot proceed forward until
I figure this one out.

>
> Your code looks good.
>
> I'm wondering if you've hit some float/double ambiguity in the C
> syntax of your compiler. I generally declare all non-array usage of
> floating point variables as doubles. Maybe try something like:
>
> while (n--) {
>
> double zin = *in++; // unambiguous typecast
> double abszin = fabs(zin);
>
> if (abszin > x->maxamp) {
> x->maxamp = abszin;
> }
> }
>
> And make sure your maxamp component is also declared double.
>
> Using double-precision is typically more efficient than
> single-precision anyway.
>
> This is a wild guess, but let us know if it helps
> --
> --------------    http://www.bek.no/~pcastine/Litter/   
> -------------
> Peter Castine             +--> Litter Power & Litter Bundle for
> Jitter
>
> iCE:  Sequencing,  Recording & Interface  Building  for Max/MSP  
> Extremely cool   http://www.dspaudio.com/
>
>

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  


I'm pretty clueless myself about max/msp thread priority and

preemption schemes, but it seems like your clock may indeed be

accessing the value of your x->value variable at when it hasn't

been properly set. I tend to take an 'empirical' approach to

debugging sometimes, so I would try messing with things like the

clock interval and the dsp signal vector size to see if that gives

Another possibility, I suppose, is that reading the sample data

isn't being done correctly (jeez I hope max 5 gets rid of that

insane w signal vector). I didn't look too closely at the code

> No, the problem persists and it is really weird.

> So I compiled a custom peakamp~ object just to show what's

> Attached is my w.peakamp~ object, its help file, and the code I

> Try opening the help file and setting the metro object with an

> of 20ms. Also set your vector size to 1024.

> It seems that every 20 ms or so my peakamp~ object outputs a zero

> The only explanation I could find is that some thread locking

> is kicking in and preventing my variables from being updated.

> However, it doesn't happen with the standard distribution

> I am working on an object that needs to implement the peakamp~

> functionality on top of other stuff and I cannot proceed forward

> > I'm wondering if you've hit some float/double ambiguity in the

> > syntax of your compiler. I generally declare all non-array

> > floating point variables as doubles. Maybe try something like:

> > double zin = *in++; // unambiguous typecast

I'm pretty clueless myself about max/msp thread priority and
preemption schemes, but it seems like your clock may indeed be
accessing the value of your x->value variable at when it hasn't
been properly set.  I tend to take an 'empirical' approach to
debugging sometimes, so I would try messing with things like the
clock interval and the dsp signal vector size to see if that gives
any clues to the behavior.

Another possibility, I suppose, is that reading the sample data
isn't being done  correctly (jeez I hope max 5 gets rid of that
insane w signal vector).  I didn't look too closely at the code
there.

> Thanks for your reply, Peter.
>
> No, the problem persists and it is really weird.
>
> So I compiled a custom peakamp~ object just to show what's
> happening...
> Attached is my w.peakamp~ object, its help file, and the code I
> wrote
> to generate the object.
> Try opening the help file and setting the metro object with an
> interval
> of 20ms. Also set your vector size to 1024.
>
> It seems that every 20 ms or so my peakamp~ object outputs a zero
> value.
> The only explanation I could find is that some thread locking
> mechanism
> is kicking in and preventing my variables from being updated.
>
> However, it doesn't happen with the standard distribution
> peakamp~.
>
> I am working on an object that needs to implement the peakamp~
> functionality on top of other stuff and I cannot proceed forward
> until
> I figure this one out.
>
> Thanks for any help.
>
> - Luigi
>
>
>
>
>
> --- Peter Castine  wrote:
>
> >
> > Your code looks good.
> >
> > I'm wondering if you've hit some float/double ambiguity in the
> C
> > syntax of your compiler. I generally declare all non-array
> usage of
> > floating point variables as doubles. Maybe try something like:
> >
> > while (n--) {
> >
> > double zin = *in++; // unambiguous typecast
> > double abszin = fabs(zin);
> >
> > if (abszin > x->maxamp) {
> > x->maxamp = abszin;
> > }
> > }
> >
> > And make sure your maxamp component is also declared double.
> >
> > Using double-precision is typically more efficient than
> > single-precision anyway.
> >
> > This is a wild guess, but let us know if it helps
> > --
> > --------------    http://www.bek.no/~pcastine/Litter/
> > -------------
> > Peter Castine             +--> Litter Power & Litter Bundle for
> > Jitter
> >
> > iCE:  Sequencing,  Recording & Interface  Building  for Max/MSP
> > Extremely cool   http://www.dspaudio.com/
> >
> >
>
>
>
> ------------------------------------------------------------
> THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT
> AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY
> UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS
> PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE
> SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES
> OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
> ------------------------------------------------------------
>
>
>
>
>
> Moody friends. Drama queens. Your life? Nope! - their life, your
> story. Play Sims Stories at Yahoo! Games.
> http://sims.yahoo.com/


I did mess with the signal vector size and the clock scheduler rate,

but still I couldn't really determine a relationship between the two.

I don't think that the problem has to do with reading the sample data,

because it's such a simple external that if you look at the code for

the DSP routine, you will see that not much can be done incorrectly.

At this point all I can ask for is help from C74.

> I'm pretty clueless myself about max/msp thread priority and

> preemption schemes, but it seems like your clock may indeed be

> accessing the value of your x->value variable at when it hasn't

> been properly set. I tend to take an 'empirical' approach to

> debugging sometimes, so I would try messing with things like the

> clock interval and the dsp signal vector size to see if that gives

> Another possibility, I suppose, is that reading the sample data

> isn't being done correctly (jeez I hope max 5 gets rid of that

> insane w signal vector). I didn't look too closely at the code

> > No, the problem persists and it is really weird.

> > So I compiled a custom peakamp~ object just to show what's

> > Attached is my w.peakamp~ object, its help file, and the code I

> > Try opening the help file and setting the metro object with an

> > of 20ms. Also set your vector size to 1024.

> > It seems that every 20 ms or so my peakamp~ object outputs a zero

> > The only explanation I could find is that some thread locking

> > is kicking in and preventing my variables from being updated.

> > However, it doesn't happen with the standard distribution

> > I am working on an object that needs to implement the peakamp~

> > functionality on top of other stuff and I cannot proceed forward

Expecting? Get great news right away with email Auto-Check. 

http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html

I did mess with the signal vector size and the clock scheduler rate,
but still I couldn't really determine a relationship between the two.

I don't think that the problem has to do with reading the sample data,
because it's such a simple external that if you look at the code for
the DSP routine, you will see that not much can be done incorrectly.

> Luigi --
>
> I'm pretty clueless myself about max/msp thread priority and
> preemption schemes, but it seems like your clock may indeed be
> accessing the value of your x->value variable at when it hasn't
> been properly set.  I tend to take an 'empirical' approach to
> debugging sometimes, so I would try messing with things like the
> clock interval and the dsp signal vector size to see if that gives
> any clues to the behavior.
>
> Another possibility, I suppose, is that reading the sample data
> isn't being done  correctly (jeez I hope max 5 gets rid of that
> insane w signal vector).  I didn't look too closely at the code
> there.
>
>
> brad
> http://music.columbia.edu/~brad
>
>
>
> Quoting Luigi Castelli :
>
> > Thanks for your reply, Peter.
> >
> > No, the problem persists and it is really weird.
> >
> > So I compiled a custom peakamp~ object just to show what's
> > happening...
> > Attached is my w.peakamp~ object, its help file, and the code I
> > wrote
> > to generate the object.
> > Try opening the help file and setting the metro object with an
> > interval
> > of 20ms. Also set your vector size to 1024.
> >
> > It seems that every 20 ms or so my peakamp~ object outputs a zero
> > value.
> > The only explanation I could find is that some thread locking
> > mechanism
> > is kicking in and preventing my variables from being updated.
> >
> > However, it doesn't happen with the standard distribution
> > peakamp~.
> >
> > I am working on an object that needs to implement the peakamp~
> > functionality on top of other stuff and I cannot proceed forward
> > until
> > I figure this one out.
> >
> > Thanks for any help.
> >
> > - Luigi
> >
> >
> >
> >
> >
> > --- Peter Castine  wrote:
> >
> > >
> > > Your code looks good.
> > >
> > > I'm wondering if you've hit some float/double ambiguity in the
> > C
> > > syntax of your compiler. I generally declare all non-array
> > usage of
> > > floating point variables as doubles. Maybe try something like:
> > >
> > > while (n--) {
> > >
> > > double zin = *in++; // unambiguous typecast
> > > double abszin = fabs(zin);
> > >
> > > if (abszin > x->maxamp) {
> > > x->maxamp = abszin;
> > > }
> > > }
> > >
> > > And make sure your maxamp component is also declared double.
> > >
> > > Using double-precision is typically more efficient than
> > > single-precision anyway.
> > >
> > > This is a wild guess, but let us know if it helps
> > > --
> > > --------------    http://www.bek.no/~pcastine/Litter/
> > > -------------
> > > Peter Castine             +--> Litter Power & Litter Bundle for
> > > Jitter
> > >
> > > iCE:  Sequencing,  Recording & Interface  Building  for Max/MSP
> > > Extremely cool   http://www.dspaudio.com/
> > >
> > >
> >
> >
> >
> > ------------------------------------------------------------
> > THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT
> > AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY
> > UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS
> > PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE
> > SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES
> > OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
> > ------------------------------------------------------------
> >
> >
> >
> >
> >
>
> > Moody friends. Drama queens. Your life? Nope! - their life, your
> > story. Play Sims Stories at Yahoo! Games.
> > http://sims.yahoo.com/
>

Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html


simulating peakamp~ behavior