Pierre Alexandre Tremblay

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.

writing-and-reading-in-a-buffer-in-the-same-block

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

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,

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?

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

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.

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

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~]).

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

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)

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?

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.

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

Quote:
The audio chain order flag has been there there in max4, too.

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

writing and reading in a buffer~ in the same block