Possible error accumulation in mstosamps~?
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 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.
Any wisdom appreciated....
\M
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.
Poke~ needs a poke into 64-bitness.
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!
\M
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~.
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.
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....
\M