Possible error accumulation in mstosamps~?


    Feb 07 2018 | 2:44 pm
    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

    • Feb 07 2018 | 3:53 pm
      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.
    • Feb 07 2018 | 4:02 pm
      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.
    • Feb 07 2018 | 11:34 pm
      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
    • Feb 08 2018 | 7:09 am
      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~.
    • Feb 16 2018 | 7:52 pm
      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.
      http://web.archive.org/web/20120516082131im_/http://cycling74.com/wp-content/themes/cycling74/img/max6-slides/Max6Slideshow-02.png
      http://web.archive.org/web/20120516082131im_/http://cycling74.com/wp-content/themes/cycling74/img/max6-slides/Max6Slideshow-02.png
    • Feb 16 2018 | 8:39 pm
      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.
    • Feb 16 2018 | 10:16 pm
      Well, whatever it is, rewriting it in gen~ fixed it....
      \M