Chris Rolfe

I have externals that write directly to buffer~'s b_samples.

Using past forum threads, the infamous index.c/buffer.h files, and T. Grill's flext as a guide, I coded my perform routine as:

In Max 5.0.3 (OS X), however, neither the buffer~ dbl-click audio window, nor waveform~ seems to redraw the recently written samples. No amount of banging or selecting seems to convince it to redraw the new samples.

To anticipate: yes, the samples are written correctly into the buffer, confirmed by writing the contents to disk.

Now, when used with record~, the waveform in Max 5 has a slick, auto-update behaviour. Is this new? Did the new updating behaviour break the old updating (by bang)?

Can 3rd parties access the new updating method? Am I not expressing the "dirtiness" of the buffer eloquently enough? It is filthy, dreckig, etc. How else can I say it? Is there a buffer_poke() routine, or some such?

Any thoughts, speculative or otherwise, are welcome.

I have externals that write directly to buffer~'s b_samples. 

Using past forum threads, the infamous index.c/buffer.h files, and T. Grill's flext as a guide, I coded my perform routine as: 

saveinuse = b->b_inuse; 
savevalid = b->b_valid; 
b->b_inuse = true; 
b->b_valid = false; 

b->b_modtime = gettime();
b->b_valid = savevalid; 
b->b_inuse = saveinuse; 

In Max 5.0.3 (OS X), however, neither the buffer~ dbl-click audio window, nor waveform~ seems to redraw the recently written samples. No amount of banging or selecting seems to convince it to redraw the new samples. 

To anticipate: yes, the samples are written correctly into the buffer, confirmed by writing the contents to disk.  

Now, when used with record~, the waveform in Max 5 has a slick, auto-update behaviour. Is this new? Did the new updating behaviour break the old updating (by bang)? 

Can 3rd parties access the new updating method? Am I not expressing the "dirtiness" of the buffer eloquently enough? It is  filthy, dreckig, etc. How else can I say it? Is there a buffer_poke() routine, or some such? 

Any thoughts, speculative or otherwise, are welcome. 

buffer-dirty-flag-and-waveform-auto-update

I can confirm that your method of dirtying used to work in 4.6.3 and does not in 5.0.3. I have my own zero-crossing-savvy record-plus~ object that I built for Hipno and been using ever since.

The waveform doesn't update based on this dirty flag method in the new Max. It doesn't look like I use the "b_valid" flag, but this method use to work...

// track record position to see if we wrote anything

    s_ptr->b_modtime = systime_ticks();

Just took a peek at the index.c source I have from 12/1/03 and it does not save the "b_valid" flag. It just gets checked to make sure the buffer is good before skipping the while loop...

So you beat me to posting about it. But now that we are here, any words from the brethren at cycling?

BTW, all of my GTK externals use the same "b_inuse" flag to make sure the buffer doesn't get destroyed while they are accessing it. This used to cause a lot of crashes circa Max 4.2 or so. If there is a new method, I have some updates I need to make.

And as an aside I'll just say the buffer example in the last SDK was *really* old and did not cover altering the buffer contents. Can we make sure that the pending update has fresher documentation?

I can confirm that your method of dirtying used to work in 4.6.3 and does not in 5.0.3.  I have my own zero-crossing-savvy record-plus~ object that I built for Hipno and been using ever since.  

The waveform doesn't update based on this dirty flag method in the new Max.  It doesn't look like I use the "b_valid" flag, but this method use to work...

// set "in use" to true
saveinuse = s_ptr->b_inuse;
s_ptr->b_inuse = true;

// track record position to see if we wrote anything
saverpos = r_pos;

// process, process, process
while ( ! done ) { do_stuff(); }

// update modtime
if (r_pos > saverpos)
	s_ptr->b_modtime = systime_ticks();

// reset "in use"
s_ptr->b_inuse = saveinuse;

Just took a peek at the index.c source I have from 12/1/03 and it does not save the "b_valid" flag.  It just gets checked to make sure the buffer is good before skipping the while loop...

So you beat me to posting about it.  But now that we are here, any words from the brethren at cycling?

BTW, all of my GTK externals use the same "b_inuse" flag to make sure the buffer doesn't get destroyed while they are accessing it.  This used to cause a lot of crashes circa Max 4.2 or so.  If there is a new method, I have some updates I need to make.

And as an aside I'll just say the buffer example in the last SDK was *really* old and did not cover altering the buffer contents.  Can we make sure that the pending update has fresher documentation?  

Thanks, Nathan, for the sanity check. I was spinning my wheels a bit.

Just to follow up, I tried dumping the published buffer.h struct while running Max's record~.

The b_modtime field is the only one obviously changing, reflecting the current gettime() (time since dsp start).One way to force a redraw is to reset the buffer to a new name, and back again.

msg to buffer~ -> set dummyName, set originalName

But, that's no good solution, of course. So I guess we're awaiting the Max 5 SDK. 

Thanks, Nathan, for the sanity check. I was spinning my wheels a bit. 

Just to follow up, I tried dumping the published buffer.h struct while running Max's record~. 

The b_modtime field is the only one obviously changing, reflecting the current gettime() (time since dsp start).One way to force a redraw is to reset the buffer to a new name, and back again. 

But, that's no good solution, of course. So I guess we're   awaiting the Max 5 SDK. 


just stumbled over that thread, having the same problem that setting 

the good old buffer->b_modtime value to gettime() doesn't update the 

Is there any known solution (like new API function etc.) for that 

Am 11.07.2008 um 02:07 schrieb Chris Rolfe:

> Thanks, Nathan, for the sanity check. I was spinning my wheels a bit.

> Just to follow up, I tried dumping the published buffer.h struct 

> The b_modtime field is the only one obviously changing, reflecting 

> the current gettime() (time since dsp start).

> One way to force a redraw is to reset the buffer to a new name, and 

> msg to buffer~ -> set dummyName, set originalName

> But, that's no good solution, of course. So I guess we're awaiting 

Hi all,
just stumbled over that thread, having the same problem that setting  
the good old buffer->b_modtime value to gettime() doesn't update the  
buffer~/waveform~ display in Max5.
Is there any known solution (like new API function etc.) for that  
issue in Max5?
gr~~~

>
> Thanks, Nathan, for the sanity check. I was spinning my wheels a bit.
>
> Just to follow up, I tried dumping the published buffer.h struct  
> while running Max's record~.
>
> The b_modtime field is the only one obviously changing, reflecting  
> the current gettime() (time since dsp start).
>
> One way to force a redraw is to reset the buffer to a new name, and  
> back again.
>
> msg to buffer~ -> set dummyName, set originalName
>
> But, that's no good solution, of course. So I guess we're   awaiting  
> the Max 5 SDK.
>
>


Resurrecting this thread from 3 years ago. Is there a solution yet?

I'm writing to a buffer but both waveform and the double-click window don't update. I am using the newish buffer_edit_begin / buffer_edit_end functions from the latest SDK, but that doesn't solve it. Manually setting the modtime didn't help me either.

Thijs, have you checked the appendix of the Max 6 SDK?

https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_appendix_d.html

Okay, it looks like there is no mention of buffer~ dirtying there. I will add that for the next SDK rev. In the meantime, all you need to add to the info in the above link is that you can make the following call from your perform routine to mark the buffer~ as having been updated:

Thijs, have you checked the appendix of the Max 6 SDK?
  https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_appendix_d.html

Okay, it looks like there is no mention of buffer~ dirtying there.  I will add that for the next SDK rev.  In the meantime, all you need to add to the info in the above link is that you can make the following call from your perform routine to mark the buffer~ as having been updated:

Yes I've read the appendix. Later I found the buffer_edit_ functions in the header and I just just guessed they might be appropriate for what I was doing. I'll use perform in combination with the dirty message.

Buffer~ dirty flag and waveform~ auto-update