Yes, this is a built-in limitation that can be modified in the source code. You could try writing a multi-array patch that uses seamless transitions or do as Andy suggested.
Or you could modify the source, and recompile.
References: http://lists.puredata.info/pipermail/pd-list/2003-04/011065.html (change source) http://lists.puredata.info/pipermail/pd-list/2003-04/011065.html (other discussion/caveats)
Actually, I just found this message from Miller (April, 2003):
'Alternatively, just specify "-maxsize 1000000000" (or whatever) in the "read" message. Oops, still no usable help window for read/writesf... I've got that in the pipe for the next release.'
(http://lists.puredata.info/pipermail/pd-list/2003-04/011069.html)
Does anybody know if this was implemented? I have no way to test right now, but that would be great.
~Kyle
On 1/31/07, padawan12 padawan12@obiwannabe.co.uk wrote:
hello everyone
iirc, there was a discussion about arrays and a problem to read huge arrays with [tabread4~]. due to a limitation of 32bit-floats, it's not possible to read huge arrays continously after a certain point, because the index cannot represent each integer, when it is higher than a certain value. i am not sure anymore, but i think, the maximum index is 2 ^ 23 = 8388608, which would make it possible to read out an array without artefacts of 8388608 / 44100 = 190s length. matju, who left this list, has explained that much nicer and more accurate. unfortunately i couldn't find that post anymore. anyway, the moral of this story is, that bigger arrays than 3min should be avoided, otherwise artefacts are expected.
roman
On Wed, 2007-01-31 at 08:48 -0600, Kyle Klipowicz wrote:
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de