Luigi Castelli

pattr-related-questions

This is one of the little nods in the direction of efficiency that I 

also make. It certainly can't hurt, and it probably helps a little 

bit. Compared to calculating FFTs or doing video interpolation, a 

symbol table lookup is a drop in the bucket, but every little bit helps.

Am 27.02.2007 um 00:48 schrieb Luigi Castelli:

> Now, does it make sense - for the sake of efficiency -

> to store global pointers to symbols specifying

> attributes names in order to avoid calling 'gensym'

> For instance, I can declare a global variable:

> object_attr_setfloat(x, ps_myattr, value);

> Does it make a difference, is it worth it? or not

This is one of the little nods in the direction of efficiency that I  
also make. It certainly can't hurt, and it probably helps a little  
bit. Compared to calculating FFTs or doing video interpolation, a  
symbol table lookup is a drop in the bucket, but every little bit helps.

> Now, does it make sense - for the sake of efficiency -
> to store global pointers to symbols specifying
> attributes names in order to avoid calling 'gensym'
> everytime?
>
> For instance, I can declare a global variable:
> t_symbol *ps_myattr;
>
> and define it in main like this:
> ps_myattr = gensym("myattr");
>
> so now I can write:
> object_attr_setfloat(x, ps_myattr, value);
>
> Does it make a difference, is it worth it? or not
> really?


As you probably have understood by now, I am working

on a MSP external that I would like to make compatible

with Pattr. Now, as it happens in many MSP objects I

can change the internal state of my object both with

messages or with signals connected to the object's

inlets. I need a way to notify Pattr that the internal

state has changed when I have a signal connected.

in the perform method? Not in the while loop, but just

Here some sample code to better show what I am trying

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

static t_int *pan_tilde_perform(t_int *w)

        long index = (long)(1024.f * value + 1024.f);

        index = CLIP(index, 0, 2048);

        float Lamp_next = gCos[index];

        float Ramp_next = gSin[index];

        float Lamp_slope = CALC_SLOPE(Lamp_next, Lamp);

        float Ramp_slope = CALC_SLOPE(Ramp_next, Ramp);

            float sig = *in++;

            *out1++ = sig * Lamp;

            *out2++ = sig * Ramp;

            Lamp += Lamp_slope;

            Ramp += Ramp_slope;

        object_notify(x->box, _sym_modified, 0L); ///

Is Max gonna choke if the user chooses a small vector

Are there different (better) techniques to achieve the

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

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.

Have a HUGE year through Yahoo! Small Business.

http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

As you probably have understood by now, I am working
on a MSP external that I would like to make compatible
with Pattr. Now, as it happens in many MSP objects I
can change the internal state of my object both with
messages or with signals connected to the object's
inlets. I need a way to notify Pattr that the internal
state has changed when I have a signal connected.

is it safe to call object_notify(x->box,
_sym_modified, 0L);
in the perform method? Not in the while loop, but just
outside.

Here some sample code to better show what I am trying
to do:

--------------------------------------------------
static t_int *pan_tilde_perform(t_int *w)
{
        t_pan_tilde *x = (t_pan_tilde *)(w[1]);
	float *in = (float *)(w[2]);
	float value = *(float *)(w[3]);
	float *out1 = (float *)(w[4]);
        float *out2 = (float *)(w[5]);
	long n = (long)(w[6]);
        float Lamp = x->Lamp;
	float Ramp = x->Ramp;

        if (x->ob.z_disabled) {
		goto out;
	}
	if (value != x->value) {
		long index = (long)(1024.f * value + 1024.f);
		index = CLIP(index, 0, 2048);
		float Lamp_next  = gCos[index];
		float Ramp_next = gSin[index];
		float Lamp_slope = CALC_SLOPE(Lamp_next, Lamp);
		float Ramp_slope = CALC_SLOPE(Ramp_next, Ramp);
		while (n--) {
			float sig = *in++;
			*out1++ = sig * Lamp;
			*out2++ = sig * Ramp;
			Lamp += Lamp_slope;
			Ramp += Ramp_slope;
		}
		x->value = value
		x->Lamp = Lamp_next;
                x->Ramp = Ramp_next;
		object_notify(x->box, _sym_modified, 0L);  ///
??????
	} else {
		while (n--) {
			float sig = *in++;
			*out1++ = sig * Lamp;
			*out2++ = sig * Ramp;
		}
	}
out:
	return w + 7;
--------------------------------------------------

Is Max gonna choke if the user chooses a small vector
size?
Are there different (better) techniques to achieve the
above?

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

Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL


Perhaps the qelem or clock functions available in the Max SDK would

help here. You could setup a timer to poll the value of your

parameters every N ms to avoid having to do something crazy in the

audio thread. See the Writing Max Externals PDF for more on these

> As you probably have understood by now, I am working

> on a MSP external that I would like to make compatible

> with Pattr. Now, as it happens in many MSP objects I

> can change the internal state of my object both with

> messages or with signals connected to the object's

> inlets. I need a way to notify Pattr that the internal

> state has changed when I have a signal connected.

> is it safe to call object_notify(x->box,

> in the perform method? Not in the while loop, but just

> Here some sample code to better show what I am trying

> --------------------------------------------------

> static t_int *pan_tilde_perform(t_int *w)

> t_pan_tilde *x = (t_pan_tilde *)(w[1]);

> long index = (long)(1024.f * value + 1024.f);

> float Lamp_slope = CALC_SLOPE(Lamp_next, Lamp);

> float Ramp_slope = CALC_SLOPE(Ramp_next, Ramp);

Hi Luigi,
Perhaps the qelem or clock functions available in the Max SDK would
help here.  You could setup a timer to poll the value of your
parameters every N ms to avoid having to do something crazy in the
audio thread.  See the Writing Max Externals PDF for more on these
functions.

On 2/27/07, Luigi Castelli  wrote:
> Hello again,
>
> As you probably have understood by now, I am working
> on a MSP external that I would like to make compatible
> with Pattr. Now, as it happens in many MSP objects I
> can change the internal state of my object both with
> messages or with signals connected to the object's
> inlets. I need a way to notify Pattr that the internal
> state has changed when I have a signal connected.
>
> is it safe to call object_notify(x->box,
> _sym_modified, 0L);
> in the perform method? Not in the while loop, but just
> outside.
>
> Here some sample code to better show what I am trying
> to do:
>
> --------------------------------------------------
> static t_int *pan_tilde_perform(t_int *w)
> {
>         t_pan_tilde *x = (t_pan_tilde *)(w[1]);
>         float *in = (float *)(w[2]);
>         float value = *(float *)(w[3]);
>         float *out1 = (float *)(w[4]);
>         float *out2 = (float *)(w[5]);
>         long n = (long)(w[6]);
>         float Lamp = x->Lamp;
>         float Ramp = x->Ramp;
>
>         if (x->ob.z_disabled) {
>                 goto out;
>         }
>         if (value != x->value) {
>                 long index = (long)(1024.f * value + 1024.f);
>                 index = CLIP(index, 0, 2048);
>                 float Lamp_next  = gCos[index];
>                 float Ramp_next = gSin[index];
>                 float Lamp_slope = CALC_SLOPE(Lamp_next, Lamp);
>                 float Ramp_slope = CALC_SLOPE(Ramp_next, Ramp);
>                 while (n--) {
>                         float sig = *in++;
>                         *out1++ = sig * Lamp;
>                         *out2++ = sig * Ramp;
>                         Lamp += Lamp_slope;
>                         Ramp += Ramp_slope;
>                 }
>                 x->value = value
>                 x->Lamp = Lamp_next;
>                 x->Ramp = Ramp_next;
>                 object_notify(x->box, _sym_modified, 0L);  ///
> ??????
>         } else {
>                 while (n--) {
>                         float sig = *in++;
>                         *out1++ = sig * Lamp;
>                         *out2++ = sig * Ramp;
>                 }
>         }
> out:
>         return w + 7;
> --------------------------------------------------
>
> Is Max gonna choke if the user chooses a small vector
> size?
> Are there different (better) techniques to achieve the
> above?
>
> Thanks for your time.
>
> - Luigi
>
>
>
>
>
> ------------------------------------------------------------
> 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.
> ------------------------------------------------------------
>
>
>
>
> Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
>


Yes, that's the obvious path to follow, however I am

curious about other techniques to accomplish the same

that do not involve the use of clocks or qelems.

If I use qelems I can still get backlogging if the

qelem function gets called too often, which might

happen if it's in the perform routine, especially with

Clocks do not have this issue because you can set a

polling interval time, however my programmer sixth

sense tells me they are not what's ideal to use in

Is it safe to use object_notify(...) directly in the

> Perhaps the qelem or clock functions available in

> help here. You could setup a timer to poll the

> parameters every N ms to avoid having to do

> audio thread. See the Writing Max Externals PDF for

> > As you probably have understood by now, I am

> > on a MSP external that I would like to make

> > with Pattr. Now, as it happens in many MSP objects

> > can change the internal state of my object both

> > messages or with signals connected to the object's

> > inlets. I need a way to notify Pattr that the

> > state has changed when I have a signal connected.

> > is it safe to call object_notify(x->box,

> > in the perform method? Not in the while loop, but

> > Here some sample code to better show what I am

> > --------------------------------------------------

> > static t_int *pan_tilde_perform(t_int *w)

> > t_pan_tilde *x = (t_pan_tilde *)(w[1]);

See all the new 2007 cars at Yahoo! Autos.

Yes, that's the obvious path to follow, however I am
curious about other techniques to accomplish the same
that do not involve the use of clocks or qelems.

If I use qelems I can still get backlogging if the
qelem function gets called too often, which might
happen if it's in the perform routine, especially with
small vector sizes.

Clocks do not have this issue because you can set a
polling interval time, however my programmer sixth
sense tells me they are not what's ideal to use in
this case.

Is it safe to use object_notify(...) directly in the
perform routine?

> Hi Luigi,
> Perhaps the qelem or clock functions available in
> the Max SDK would
> help here.  You could setup a timer to poll the
> value of your
> parameters every N ms to avoid having to do
> something crazy in the
> audio thread.  See the Writing Max Externals PDF for
> more on these
> functions.
>
> wes
>
> On 2/27/07, Luigi Castelli 
> wrote:
> > Hello again,
> >
> > As you probably have understood by now, I am
> working
> > on a MSP external that I would like to make
> compatible
> > with Pattr. Now, as it happens in many MSP objects
> I
> > can change the internal state of my object both
> with
> > messages or with signals connected to the object's
> > inlets. I need a way to notify Pattr that the
> internal
> > state has changed when I have a signal connected.
> >
> > is it safe to call object_notify(x->box,
> > _sym_modified, 0L);
> > in the perform method? Not in the while loop, but
> just
> > outside.
> >
> > Here some sample code to better show what I am
> trying
> > to do:
> >
> > --------------------------------------------------
> > static t_int *pan_tilde_perform(t_int *w)
> > {
> >         t_pan_tilde *x = (t_pan_tilde *)(w[1]);
> >         float *in = (float *)(w[2]);
> >         float value = *(float *)(w[3]);
> >         float *out1 = (float *)(w[4]);
> >         float *out2 = (float *)(w[5]);
> >         long n = (long)(w[6]);
> >         float Lamp = x->Lamp;
> >         float Ramp = x->Ramp;
> >
> >         if (x->ob.z_disabled) {
> >                 goto out;
> >         }
> >         if (value != x->value) {
> >                 long index = (long)(1024.f * value
> + 1024.f);
> >                 index = CLIP(index, 0, 2048);
> >                 float Lamp_next  = gCos[index];
> >                 float Ramp_next = gSin[index];
> >                 float Lamp_slope =
> CALC_SLOPE(Lamp_next, Lamp);
> >                 float Ramp_slope =
> CALC_SLOPE(Ramp_next, Ramp);
> >                 while (n--) {
> >                         float sig = *in++;
> >                         *out1++ = sig * Lamp;
> >                         *out2++ = sig * Ramp;
> >                         Lamp += Lamp_slope;
> >                         Ramp += Ramp_slope;
> >                 }
> >                 x->value = value
> >                 x->Lamp = Lamp_next;
> >                 x->Ramp = Ramp_next;
> >                 object_notify(x->box,
> _sym_modified, 0L);  ///
> > ??????
> >         } else {
> >                 while (n--) {
> >                         float sig = *in++;
> >                         *out1++ = sig * Lamp;
> >                         *out2++ = sig * Ramp;
> >                 }
> >         }
> > out:
> >         return w + 7;
> > --------------------------------------------------
> >
> > Is Max gonna choke if the user chooses a small
> vector
> > size?
> > Are there different (better) techniques to achieve
> the
> > above?
> >
> > Thanks for your time.
> >
> > - Luigi
> >
> >
> >
> >
> >
> >
>
------------------------------------------------------------
> > 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.
> >
>
------------------------------------------------------------
> >
> >
> >
> >
> >
>
> > Get your own web address.
> > Have a HUGE year through Yahoo! Small Business.
> > http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
> >
>

Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html


On Feb 27, 2007, at 9:49 AM, Luigi Castelli wrote:

> If I use qelems I can still get backlogging if the

> qelem function gets called too often, which might

> happen if it's in the perform routine, especially with

No. Using *one* qelem or clock explicitly *prevents* backlogging, 

since they are single events. As compared with defer(low) or schedule 

which lead to a generation of new events one for each call. This is 

> Is it safe to use object_notify(...) directly in the

> If I use qelems I can still get backlogging if the
> qelem function gets called too often, which might
> happen if it's in the perform routine, especially with
> small vector sizes.

No. Using *one* qelem or clock explicitly *prevents* backlogging,  
since they are single events. As compared with defer(low) or schedule  
which lead to a generation of new events one for each call. This is  
the ideal way to accomplish this.

> Is it safe to use object_notify(...) directly in the
> perform routine?

so what's the difference between a clock and a qelem?

Which one is most appropriate in this situation?

> On Feb 27, 2007, at 9:49 AM, Luigi Castelli wrote:

> > If I use qelems I can still get backlogging if the

> > qelem function gets called too often, which might

> > happen if it's in the perform routine, especially

> No. Using *one* qelem or clock explicitly *prevents*

> since they are single events. As compared with

> which lead to a generation of new events one for

> > Is it safe to use object_notify(...) directly in

Download and play hundreds of games for free on Yahoo! Games.

so what's the difference between a clock and a qelem?
Which one is most appropriate in this situation?

>
> On Feb 27, 2007, at 9:49 AM, Luigi Castelli wrote:
>
> > If I use qelems I can still get backlogging if the
> > qelem function gets called too often, which might
> > happen if it's in the perform routine, especially
> with
> > small vector sizes.
>
> No. Using *one* qelem or clock explicitly *prevents*
> backlogging,  
> since they are single events. As compared with
> defer(low) or schedule  
> which lead to a generation of new events one for
> each call. This is  
> the ideal way to accomplish this.
>
> > Is it safe to use object_notify(...) directly in
> the
> > perform routine?
>
> No.
>
> -Joshua
>

Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front


On Feb 27, 2007, at 10:36 AM, Luigi Castelli wrote:

> so what's the difference between a clock and a qelem?

Please read dev doc. clock == scheduler event. qelem == low priority 

> Which one is most appropriate in this situation?

Please read dev doc. clock == scheduler event. qelem == low priority  
queue event.

Pattr related questions