drumwell

just a little note that there appears to be a bug in the pictmeter~ example in the currently-available version of the SDK (MaxSDK-5.0.6r2).

building this object out-of-the-box and then opening the provided help patch results in the following error message in the max window:

"signal outlet (phasor~) connected to nonsignal inlet (pictmeter~)"

also, nothing happens when you open the pict file and turn on the ezdac~.

i'm not sure if anyone else ran into this post-expo, but i did. fortunately, it seems to be easy to fix by commenting out the following line in main:

according to my read of the documentation, it looks like the following line, called before class_dspinit, handles the necessarily initialization for the newly defined class:

re-compiling and running without class_dspinit seems to produce good, working results.

building this object out-of-the-box and then opening the provided help patch results in the following error message in the max window:
"signal outlet (phasor~) connected to nonsignal inlet (pictmeter~)"

also, nothing happens when you open the pict file and turn on the ezdac~. 

i'm not sure if anyone else ran into this post-expo, but i did. fortunately, it seems to be easy to fix by commenting out the following line in main:  

re-compiling and running without class_dspinit seems to produce good, working results. 

bug-in-pictmeter-example

 line. This has been fixed for the next version of the SDK.

That's correct you need to comment the class_dspinit() line. This has been fixed for the next version of the SDK.

in class today here in cnmat - we're wondering if there's any reason there's no critical regions in pictmeter~. It does seem that there needs to be some thread management, since we're reading dsp values and using them in the graphics drawing thread, which are both scheduled differently.

Is the lack of critical regions in the pictmeter~ example because the author didn't bother, or is unnecessary due to some built-in safety that keeps us minions from having to bother?

Critical regions have actually come up a lot this week, so I'm trying to get a handle on them!

in class today here in cnmat - we're wondering if there's any reason there's no critical regions in pictmeter~. It does seem that there needs to be some thread management, since we're reading dsp values and using them in the graphics drawing thread, which are both scheduled differently.
Is the lack of critical regions in the pictmeter~ example because the author didn't bother, or is unnecessary due to some built-in safety that keeps us minions from having to bother?

Critical regions have actually come up a lot this week, so I'm trying to get a handle on them!


bearing in mind that i have approximately one week experience as a max/msp developer, in the case of this example the exact sequencing of the redraw and the input processing don't seem to matter much. it's just a peak meter, and the ballistics are such that it gets drawn every 1/10 of a second, and when it gets drawn (or, more precisely, when it asks to be redrawn) the peak value is reset to 0. hence, not much to worry about in terms of thread-safe processing and drawing.

the pictmeter_tick() function could get interrupted during either of these lines:

...
x->p_value = x->p_max;
x->p_max = 0;
...


possibly leaving either containing nonsense. But both of these are probably going to be executed atomically so

possibly leaving either containing nonsense. But both of these are probably going to be executed atomically so it shouldn't be a problem.

bug in pictmeter~ example