gr@grrrr.org

in pre-Max-5 times external developers used to mark a buffer as modified by updating a designated data element of the buffer structure: 

Obviously something has changed in Max5 so that this does no longer trigger visual update in waveform~ etc.

How would i mark a buffer as dirty in Max5?

Hi all,
in pre-Max-5 times external developers used to mark a buffer as modified by updating a designated data element of the buffer structure: 
p->b_modtime = gettime();

Obviously something has changed in Max5 so that this does no longer trigger visual update in waveform~ etc.
How would i mark a buffer as dirty in Max5?

visual-buffer-update

I just wrote up the following about buffer~ access in Max 5. I hope it helps:

http://blog.74objects.com/2009/03/22/accessing-buffers/

I just wrote up the following about buffer~ access in Max 5.  I hope it helps:

Thanks for the info on your blog! I think the answer Thomas needs is that he should send the message "dirty" to his buffer. But I'm interested in the "new sheriff" you mentioned on your blog:

Following that you have an access loop without checking at each sample to see if the buffer is still valid. Does the "sheriff" make that safe to do?

What I've tried recently (seems to work, but I don't do a lot of active buffer switching) is to check before each sample access if b_valid is still true. If not, I bail. Is that hideously expensive, still not thread-safe, or otherwise sub-optimal?

So is this "new sheriff" method why my waveforms have not been updating? I am guessing that objects that use the old method are no longer properly notifying the waveform UI?

Tim it is my [record_plus~] object that has been doing this to me (we used it in Hipno). Sometimes the waveform would draw and sometimes not. I have been trying to pin down this bug for a while before reporting.

This smells like a winning explanation though. Just curious.

Guess I need to block off some time to code. *sigh*

So is this "new sheriff" method why my waveforms have not been updating?  I am guessing that objects that use the old method are no longer properly notifying the waveform UI?

Tim it is my [record_plus~] object that has been doing this to me (we used it in Hipno). Sometimes the waveform would draw and sometimes not.  I have been trying to pin down this bug for a while before reporting.  

This smells like a winning explanation though.  Just curious.

Guess I need to block off some time to code. *sigh*
--Nathan


visual buffer update