writing and reading in a buffer~ in the same block

Oct 18, 2009 at 2:30pm

writing and reading in a buffer~ in the same block

Dear all

We used to be able to do this in Max 4.6: indexing a buffer~ with count~ in read and write at the same time (i.e. putting the same address in poke~ and index~) and we were sure it was working.

Now in Max5 I get some nasty artefacts, as in the very simplifies patch included.

Is that normal?

thanks

pa

– Pasted Max Patch, click to expand. –
#45938
Oct 18, 2009 at 5:05pm
Quote:
We used to be able to do this in Max 4.6: indexing a buffer~ with count~ in read and write at the same time (i.e. putting the same address in poke~ and index~) and we were sure it was working.
Now in Max5 I get some nasty artefacts,

you can still do this. start [count~] with a bang, and it should work. if you want to stop/pause recording, set the sample index (second inlet of poke~) to -1.

but i remember some funkiness with the order of creation of the signal obejects, so you might still run into problems…

volker

#165531
Oct 20, 2009 at 10:21am

this is a patch that makes sure it works, but it still pisses me off that it use to read than write, respecting the right-to-left rule, and now it seems to be random! with one Signal Vector delay, it works…

can this behavious be confirmed by any cycling coder?

p

– Pasted Max Patch, click to expand. –
#165532
Oct 20, 2009 at 3:25pm

I don’t think, there’s anything wrong or random here…
The first patch posted didn’t work because [count~] doesn’t get started. So only _one_ sample (the first) was read/written.
As volker said, send [count~] a bang and everythings fine (without needing a [delay~]).

You can even feedback the [index~] back into the [poke~]. This of course introduces a delay of one vector block (like send~/receive~), as this patch demonstrates.

Quote:it still pisses me off that it use to read than write, respecting the right-to-left rule, and now it seems to be random

BTW, I don’t think, that the right-to-left rule applies to signals.
In the SDK there’s a Z_PUT_FIRST and Z_PUT_LAST flag for signal objects, which tells the audio scheduler to put it near the end or beginning of the signal chain. But the docs don’t go into detail…

– Pasted Max Patch, click to expand. –
#165533
Oct 20, 2009 at 4:14pm

I think you are right about the new order, but it use to work right to left in max 4.6 or I am wrong but I have coded since MSP1 with that assumption and was never told wrong i.e. my code worked!

btw, I’ve added 1 as a second argument to count~ and it does not solve my problem, every other time!

it is very unpredictible, which is quite new to Max5, hence my questions…

Thanks for your help, the second patch I posted is working, but I want to know if the thread-safe buffer access is the responsible (which I think it is) but your idea of the audio chain order is a good hypothesis (again just in Max5… maybe to sort the problem induced by the increment/decrement of the b_inuse flag)

pa

#165534
Oct 20, 2009 at 6:18pm

Ok, maybe my answer was a bit naive. I hadn’t thought about the new thread/multiprocessor-safe buffer access.
The audio chain order flag has been there there in max4, too.

Anyways, I haven’t noticed any artifacts opening the patch several times!

Maybe you should post this in the Dev-forum?

#165535
Oct 20, 2009 at 7:40pm
Quote:
The audio chain order flag has been there there in max4, too.

I didn’t notice… I’ve been lucky then!

Quote:
Maybe you should post this in the Dev-forum?

I’ll flag it, you are right. I sent it to the bek list as well, and some interesting answers came from there…

cheers

pa

#165536

You must be logged in to reply to this topic.