Trying to understand buffer~'s upper size limit

    11olsen
    Aug 20 2017 | 1:50 pm
    First it seems logical: the maximum size i can set is 268435455. (more causes "bad size" error) As the size limit is somehow related to the maximum of a 32bit int which is 2147483647, i concluded 2147483647 / 4 (bytes per float) / 2 (floats per channel) = 268435455 ;
    But why is the limit the same if i use a buffer with 1, 2 or with 4 channels? It seems the channels do not affect the possible size. But what's the proper calculation of the upper limit then? And don't we have 64bit OS and Max to overcome 32bit addressing problems?
    • Floating Point
      Aug 20 2017 | 11:29 pm
      it might be 8 bytes per float (64 bits precision makes sense) and channel-independent (which makes sense if the buffer is structured as a 2-d array of frames)
    • 11olsen
      Aug 20 2017 | 11:54 pm
      I'm not sure https://cycling74.com/sdk/max-sdk-7.3.3/html/group__buffers.html#details says While the Max 6 signal processing chain operates on 64-bit double-precision floats, the t_buffer_obj storage remains as 32-bit single-precision float format. This is essential to maintain backward compatibility with older third-party externals. Otherwise we could insert and extract double arrays in externals.
      You might be correct with the 2-d Array, the "sizeinsamps" message schould be called "sizeinframes" probably.