Hi IOhannes !
Thanks for very particular answer and looking through the patch !
The only puprose with wich i do this complex resizing is that i need to play large audio files. The "-resize" tag somehow doesn't allow the samples longer then one-two minutes.. That was my initial issue, when starting this thread.
The useful answer i found was: http://puredata.hurleur.com/sujet-4301-pausing-resuming-playback-multiple-la...
" For those who don't know, you can resize a table with a message like so:
[; table_name resize 158760000;(
I like to set a max-size with a message like this, load a file into the table with [soundfiler], and then send the "total samples" output of [soundfiler] to another resize message to be sure there isn't any empty space after the loaded file."
Later i found the example patch made by the guy (in attach). And it works well. You can reload files of different lenght into it. But it is only for mono.
My attempt was to make the same thing for stereo, which is just doubling everything. My system has 6 GB of OM and 4 is available (Win7), but i'm agree that it is not elegant solution to resize tables like that.. anyway in my code they are resized one after another.. so in my logic that should have been working. But it doesn't. Did you try to play long stereo files in PD and reload them ? What can be the way ?
thanks !
Пятница, 19 июля 2013, 9:54 +02:00 от IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-07-19 03:49, Фывапр Олджэвич wrote:
Dear List !
I made this patch to play long stereo audio file. You can load audiofile and play, but before - reset the sizes of tables.
BUT, it plays only one stereo file in my Vanilla. So when i played one file and try to load another: i push the RESET-bang .. and PD crushes totally..
well, i don't think it's Pd that's crashing - but rather the operating system that kills it.
why? at the beginning you create 2 tables and resize them to 1 (what is this for?) and then to 158760000 samples. given that Pd uses 4 bytes to save each sample (8 bytes on 64bit), this means that one table takes approximately 635MB (32bit) resp 1.27GB (64bit). so this gives you (for both tables) 1.27GB (32bit) resp 2.5GB (64bit) memory consumption. now when loading the table, you resize it, which potentially means allocating a new table which is bigger than the previous one, copying the data from the old table to the new one and then freeing the old table. so at some point you have doubled the amount of memory needed by your patch.
how much RAM do you have? is your system/OS capable of addressing more than 4GB of memory? (e.g. PAE) is your system/OS capable of addressing more than 4GB of memory within a single application? (64bit)
apart from that you patch is slightly buggy anyhow. imaging the following scenario:
- init tables with 1h of samples
- load a soundfile that is 3 seconds long
(the sample gets loaded and the table gets resized to 3 seconds)
- load a soundfile that is 10 minutes long:
the sample gets loaded into the 3 seconds table and is truncated. after that, the table is resized to 10 minutes - giving you 3 seconds of your soundfile and 9:57 of silence.
did you know that [soundfiler] has a "-resize" switch that automatically resizes the table to your needs? btw, you might even want to resize your table to something small (1) before loading the sample.
adgmsr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlHo8LEACgkQkX2Xpv6ydvTCJQCeJ5LygzizivKw41LEzg0MSuBi ozEAn0QvwPIZhI9e5BROlq6Xj/RP0Id/ =Fn0N -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list