Forums > Dev

Buffer~ dirty flag and waveform~ auto-update

July 10, 2008 | 2:29 am

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;

while ( ! done ) { do_stuff(); }

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.

Cheers,
Chris


July 10, 2008 | 12:57 pm

Chris:

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…

if (!b->b_valid)
goto zero;

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?

–Nathan


July 11, 2008 | 12:07 am

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.


February 18, 2009 | 10:00 pm

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

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


July 8, 2012 | 2:32 pm

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.

Any news on this?


July 11, 2012 | 4:44 pm

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

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

(shuffle, shuffle)

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:

object_method(b, gensym("dirty"));

HTH,
Tim


July 12, 2012 | 10:03 pm

Hi Tim,

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.

Thanks!
Thijs


Viewing 7 posts - 1 through 7 (of 7 total)