mattyo

I've been working on a patch which writes to arbitrary locations in a multichannel buffer~ Since I'm only writing to one track at a time, and don't want to overwrite, I'm using poke~ rather than record~ to write to the buffer. Start/endpoints I'm writing to are given in ms, and I'm using mstosamps~ plus count~ to set the location in the buffer~ I'm writing to.

The problem is this: if I write to the buffer~ past the 12-minute point or so, I'm getting a lot of distortion -- is this something related to accumulating errors in mstosamps~ once the ms values get very high?

Below is a schematic of the basic mechanism, in case the above isn't clear.

comment

buffer~

cycle~

button

number

mstosamps~

count~

poke~

I've been working on a patch which writes to arbitrary locations in a multichannel buffer~ Since I'm only writing to one track at a time, and don't want to overwrite, I'm using poke~ rather than record~ to write to the buffer. Start/endpoints I'm writing to are given in ms, and I'm using mstosamps~ plus count~ to set the location in the buffer~ I'm writing to.

The problem is this: if I write to the buffer~ past the 12-minute point or so, I'm getting a lot of distortion -- is this something related to accumulating errors in mstosamps~ once the ms values get very high?

Hello,
I've been working on a patch which writes to arbitrary locations in a multichannel buffer~ Since I'm only writing to one track at a t

possible-error-accumulation-in-mstosamps~

mstosams isn't accumulating anything, it just multiplies ms with samplerate.

Maybe Your problem is rather related to +~.

I would send mstosamps~ float (right) output directly to count~ to set

counting position, and stop the count when no recording takes place.

mstosams isn't accumulating anything, it just multiplies ms with samplerate.
Maybe Your problem is rather related to +~.
I would send mstosamps~ float (right) output directly to count~ to set
counting position, and stop the count when no recording takes place.


It seems that C74 didn't update poke~ object for a longer while, and it shrinks index values to 32-bit floats. Redone in gen~ produces clear signal.

Ah, I thought it might have been a 32-bit type error, although I got the wrong object) but I thought everything had been updated to 64-bit. Had I not heard an answer I wanted, gen~ was going to be my next step. Thanks!

Audio objects in MSP~ communicate with each other and the outside world in 32-bit float. The 64-bit float is inside some things like gen~.

Nope, my friend. Since Max6 MSP is running on 64-bit. Only buffers are kept in 32-bit for obvious reasons.

Max6Slideshow-02.png

If MAx7 does everything ELSE in 64-bit EXCEPT buffers~ then obviously Max8 will have to fix that, as type conversion is very expensive CPU wise.

If MAx7 does everything ELSE  in 64-bit EXCEPT buffers~ then obviously Max8 will have to fix that, as type conversion is very expensive CPU wise. 

Well, whatever it is, rewriting it in gen~ fixed it....

Possible error accumulation in mstosamps~?