Hello List,
I recently encountered a problem while developing a patch. I get audio drops when I load a sample to a table. Now, I know this is an issue as explained here:
https://puredata.info/docs/tutorials/TipsAndTricks#how-to-avoid-audio-drop-o...
there are some situations, where audio drop outs can occur. if you know why a certain kind of drop-happens, you probably will find a way to overcome the problem.
- fileIO: all objects, that read files from disk, will block audio,
until they finished executing. so do load all files beforehand. when you need to load soundfiles during performance into tables, don't use [soundfiler]. miller once suggested using [readsf~] in a subpatch with upsampling, so it will load the sample faster than reading it in realtime, but not block dsp during loadtime. it seems, that some people do load only the very first part of each file, that will be used during a performance into a table, and do read the rest from disk.
The problem that I have, is that I need to use soundfiler as I am stretching the sound with fft and it needs to read it within a table. Is there a soundfiler alternative or a way to load a file into a table differently?
any help will be appreciated.
thank you
Just a couple of thoughts:
If you don't need to load too many files you can have them preloaded on some subpatch.
If they are many and constantly changing you can try using a portion of your RAM as a virtual HDD, this overrides all fiscal bottleneck of disk IO.
https://en.wikipedia.org/wiki/RAM_drive
https://en.wikipedia.org/wiki/List_of_RAM_drive_software
On Windows I used “ImDisk Virtual Disk Driver”
http://www.ltr-data.se/opencode.html/
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of José Rafael Subía Valdez jsubiavaldez@gmail.com Sent: Monday, February 27, 2017 5:16 PM To: pd-list Subject: [PD] soundfiler alternative?
Hello List,
I recently encountered a problem while developing a patch. I get audio drops when I load a sample to a table. Now, I know this is an issue as explained here:
https://puredata.info/docs/tutorials/TipsAndTricks#how-to-avoid-audio-drop-o...
there are some situations, where audio drop outs can occur. if you know why a certain kind of drop-happens, you probably will find a way to overcome the problem.
- fileIO: all objects, that read files from disk, will block audio, until they finished executing. so do load all files beforehand. when you need to load soundfiles during performance into tables, don't use [soundfiler]. miller once suggested using [readsf~] in a subpatch with upsampling, so it will load the sample faster than reading it in realtime, but not block dsp during loadtime. it seems, that some people do load only the very first part of each file, that will be used during a performance into a table, and do read the rest from disk.
The problem that I have, is that I need to use soundfiler as I am stretching the sound with fft and it needs to read it within a table. Is there a soundfiler alternative or a way to load a file into a table differently?
any help will be appreciated.
thank you
-- José Rafael Subía Valdez www.jrsv.nethttp://www.jrsv.net
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
thanks .. anyone else?
On Mon, Feb 27, 2017 at 5:53 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Just a couple of thoughts:
If you don't need to load too many files you can have them preloaded on some subpatch.
If they are many and constantly changing you can try using a portion of your RAM as a virtual HDD, this overrides all fiscal bottleneck of disk IO.
https://en.wikipedia.org/wiki/RAM_drive
https://en.wikipedia.org/wiki/List_of_RAM_drive_software
On Windows I used “ImDisk Virtual Disk Driver”
http://www.ltr-data.se/opencode.html/
Mensaje telepatico asistido por maquinas.
*From:* Pd-list pd-list-bounces@lists.iem.at on behalf of José Rafael Subía Valdez jsubiavaldez@gmail.com *Sent:* Monday, February 27, 2017 5:16 PM *To:* pd-list *Subject:* [PD] soundfiler alternative?
Hello List,
I recently encountered a problem while developing a patch. I get audio drops when I load a sample to a table. Now, I know this is an issue as explained here:
https://puredata.info/docs/tutorials/TipsAndTricks#how- to-avoid-audio-drop-outs
there are some situations, where audio drop outs can occur. if you know why a certain kind of drop-happens, you probably will find a way to overcome the problem.
- fileIO: all objects, that read files from disk, will block audio,
until they finished executing. so do load all files beforehand. when you need to load soundfiles during performance into tables, don't use [soundfiler]. miller once suggested using [readsf~] in a subpatch with upsampling, so it will load the sample faster than reading it in realtime, but not block dsp during loadtime. it seems, that some people do load only the very first part of each file, that will be used during a performance into a table, and do read the rest from disk.
The problem that I have, is that I need to use soundfiler as I am stretching the sound with fft and it needs to read it within a table. Is there a soundfiler alternative or a way to load a file into a table differently?
any help will be appreciated.
thank you
-- José Rafael Subía Valdez www.jrsv.net
In cyclone, we got plans to clone [buffer~] as a compiled external, it should not cause audio drops and could be an alternative to [soundfiler].
For now, in cyclone 0.3 alpha 1 (just released), [buffer~] is a new abstraction external, based on [soundfiler], so it's causing audio drop outs.
Anyway, we needed others to help us in the development of [buffer~] as an external, please let us know if anyone is interested in collaborating. I was able to do this abstraction as a prototype for now, but I'm counting on help to get it done as an external.
cheers
2017-02-27 15:06 GMT-03:00 José Rafael Subía Valdez jsubiavaldez@gmail.com :
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
thanks .. anyone else?
On Mon, Feb 27, 2017 at 5:53 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Just a couple of thoughts:
If you don't need to load too many files you can have them preloaded on some subpatch.
If they are many and constantly changing you can try using a portion of your RAM as a virtual HDD, this overrides all fiscal bottleneck of disk IO.
https://en.wikipedia.org/wiki/RAM_drive
https://en.wikipedia.org/wiki/List_of_RAM_drive_software
On Windows I used “ImDisk Virtual Disk Driver”
http://www.ltr-data.se/opencode.html/
Mensaje telepatico asistido por maquinas.
*From:* Pd-list pd-list-bounces@lists.iem.at on behalf of José Rafael Subía Valdez jsubiavaldez@gmail.com *Sent:* Monday, February 27, 2017 5:16 PM *To:* pd-list *Subject:* [PD] soundfiler alternative?
Hello List,
I recently encountered a problem while developing a patch. I get audio drops when I load a sample to a table. Now, I know this is an issue as explained here:
https://puredata.info/docs/tutorials/TipsAndTricks#how-to- avoid-audio-drop-outs
there are some situations, where audio drop outs can occur. if you know why a certain kind of drop-happens, you probably will find a way to overcome the problem.
- fileIO: all objects, that read files from disk, will block audio,
until they finished executing. so do load all files beforehand. when you need to load soundfiles during performance into tables, don't use [soundfiler]. miller once suggested using [readsf~] in a subpatch with upsampling, so it will load the sample faster than reading it in realtime, but not block dsp during loadtime. it seems, that some people do load only the very first part of each file, that will be used during a performance into a table, and do read the rest from disk.
The problem that I have, is that I need to use soundfiler as I am stretching the sound with fft and it needs to read it within a table. Is there a soundfiler alternative or a way to load a file into a table differently?
any help will be appreciated.
thank you
-- José Rafael Subía Valdez www.jrsv.net
-- José Rafael Subía Valdez www.jrsv.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 02/27/2017 07:06 PM, José Rafael Subía Valdez wrote:
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems), whereas most soundfiles will use less bytes. so having them on a RAM-disk, could indeed help.
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
it is not such a simple thing if you care for deterministic sample-synchronous playback (you personally might not care, but Pd does). however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough. it's not exactly super-cheap, but writing software isn't either.
gfmdsar IOhannes
Best is to have all soundfiles preloaded.
RAM-Disk will help if the soundfiles are short. (this skips the “seek time” of a real hard disk)
Even without RAM-disk this is related to your actual Audio-settings “delay ms” : more delay more large files without audio drops.
Don't know exactly what your patch is about.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of zmoelnig@iem.at zmoelnig@iem.at Sent: Monday, February 27, 2017 8:10 PM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler alternative?
On 02/27/2017 07:06 PM, José Rafael Subía Valdez wrote:
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems), whereas most soundfiles will use less bytes. so having them on a RAM-disk, could indeed help.
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
it is not such a simple thing if you care for deterministic sample-synchronous playback (you personally might not care, but Pd does). however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough. it's not exactly super-cheap, but writing software isn't either.
gfmdsar IOhannes
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
Christof
Gesendet: Montag, 27. Februar 2017 um 21:10 Uhr Von: zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 07:06 PM, José Rafael Subía Valdez wrote:
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems), whereas most soundfiles will use less bytes. so having them on a RAM-disk, could indeed help.
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
it is not such a simple thing if you care for deterministic sample-synchronous playback (you personally might not care, but Pd does). however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough. it's not exactly super-cheap, but writing software isn't either.
gfmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&a...)
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
- IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr Von: "IOhannes m zmölnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thank you all..
but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.
the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances.
Thanks again
On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi christof.ressi@gmx.at wrote:
i keep forgetting of abominations like running a 32-bit Pd on a 64-bit
OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en- us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID= TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=( 94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g)()
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
- IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr Von: "IOhannes m zmölnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit
OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit
process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 2017-02-28 07:42, José Rafael Subía Valdez wrote:
Thank you all..
but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world
just to make sure: i'm totally aware that my advice was targetted at a rich western society. with all the problems that arise from that.
So not really wanna discuss finances.
but of course you are.
and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.
the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample.
you might want to look at the "iem16" library i once wrote to provide a (packed) 16bit storage of audio data. it allows you to preload much more data, at a possible loss of data precision (but your WAV files are probably still 16bit only, so you won't lose anything here). it needs to be compiled though, and afaics deken only has binaries for OSX and linux so you might need to provide a w32 binary for your friends that can afford to buy a w32 machine.
fgamsdr IOhannes
Thanks again
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle.
basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms!
note that it needs soundfile_info from iemlib.
[soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0.
Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate). Hope that helps!
Christof
Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" jsubiavaldez@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
Thank you all.. but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of. the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances. Thanks again On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&a...)]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
- IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr Von: "IOhannes m zmölnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l... --
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Hey Christof and Jean-Yves Gratius
Thanks, I am opening them up just now. Christof, your patch gives me these errors when I try it out:
soundfiler_read: truncated to 44100 elements -> this one is repeated by the amount of blocks it will take to completely load the sound file resize failed
any idea why?? (before I start dismantling it?)
Cheers Guys, much appreciated.
On Tue, Feb 28, 2017 at 11:35 AM, Christof Ressi christof.ressi@gmx.at wrote:
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle.
basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms!
note that it needs soundfile_info from iemlib.
[soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0.
Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate).
Hope that helps!
Christof
Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" jsubiavaldez@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
Thank you all..
but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.
the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances.
Thanks again
On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at [mailto:christof.ressi@gmx.at]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en- us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPS twNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e 0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en-us/ library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStw Nw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b 4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z 6NjEgcaJn8pbbYAema89g)()]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
- IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr Von: "IOhannes m zmölnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit
OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit
process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
stinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] --
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net]
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists. puredata.info/listinfo/pd-list]
That's what I meant with:
[soundfiler] will vomit at you in the Pd console but you can simply
ignore it by setting the log level to 0.
I know why it happens but it doesn't really matter. Despite its flashy read appearance it's just a warning which can be safely ignored.
The patch itself should work. Tweek the amount of samples per DSP block to find a setting which works for you without dropouts.
On 28.02.2017 12:54, José Rafael Subía Valdez wrote:
Hey Christof and Jean-Yves Gratius
Thanks, I am opening them up just now. Christof, your patch gives me these errors when I try it out:
soundfiler_read: truncated to 44100 elements -> this one is repeated by the amount of blocks it will take to completely load the sound file resize failed
any idea why?? (before I start dismantling it?)
Cheers Guys, much appreciated.
On Tue, Feb 28, 2017 at 11:35 AM, Christof Ressi <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> wrote:
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle. basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms! note that it needs soundfile_info from iemlib. [soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0. Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate). Hope that helps! Christof Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" <jsubiavaldez@gmail.com <mailto:jsubiavaldez@gmail.com>> An: Pd-List <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> Betreff: Re: [PD] soundfiler alternative? Thank you all.. but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of. the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances. Thanks again On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>[mailto:christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW). > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB. here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()] <https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29]> I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems. > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. :-o. time to finally get my dual boot. I weren't so lazy... Christof * IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky) ** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB. > Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr > Von: "IOhannes m zmölnig" <zmoelnig@iem.at <mailto:zmoelnig@iem.at>[mailto:zmoelnig@iem.at <mailto:zmoelnig@iem.at>]> > An: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>[mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>] > Betreff: Re: [PD] soundfiler alternative? > > On 02/27/2017 10:45 PM, Christof Ressi wrote: > >> well, [table] stores the samples as floating point (taking 4 bytes per > >> sample; and 8 byte on 64bit systems), > > It depends on your Pd (32-bit or 64-bit), not on the system. > > well yes, true. > i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. > > > > >> however, there is a simple solution at hand: get youself plenty of RAM > >> and pre-load everything into tables. > >> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw > >> audio, which is probably enough. > > Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory"). > > how much RAM does that machine have? > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) > > but yes, in order to make use of 32GB of memory you need a native 64bit > application (running on a 64bit OS). > > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. > > gmsr > IOhannes > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] <https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D> > _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] <https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D> -- José Rafael Subía Valdez www.jrsv.net <http://www.jrsv.net>[http://www.jrsv.net <http://www.jrsv.net>] _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] <https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D>-- José Rafael Subía Valdez www.jrsv.net http://www.jrsv.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Okay, update with all the solutions everyone has chipped in. (THANKS AGAIN)
both Christof's and Jack's solution still create audio drops. Now I am testing Jean-Yves's patch and seems to do the trick.
again, thank you all. If anyone has another idea, I will be interested in looking at other solutions (just for the heck of it).
ps. Thanks Jack, I will try changing the [block]
cheers
On Tue, Feb 28, 2017 at 12:28 PM, Christof Ressi christof.ressi@gmx.at wrote:
That's what I meant with:
[soundfiler] will vomit at you in the Pd console but you can simply
ignore it by setting the log level to 0.
I know why it happens but it doesn't really matter. Despite its flashy read appearance it's just a warning which can be safely ignored.
The patch itself should work. Tweek the amount of samples per DSP block to find a setting which works for you without dropouts.
On 28.02.2017 12:54, José Rafael Subía Valdez wrote:
Hey Christof and Jean-Yves Gratius
Thanks, I am opening them up just now. Christof, your patch gives me these errors when I try it out:
soundfiler_read: truncated to 44100 elements -> this one is repeated by the amount of blocks it will take to completely load the sound file resize failed
any idea why?? (before I start dismantling it?)
Cheers Guys, much appreciated.
On Tue, Feb 28, 2017 at 11:35 AM, Christof Ressi <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> wrote:
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle. basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms! note that it needs soundfile_info from iemlib. [soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0. Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate). Hope that helps! Christof Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" <jsubiavaldez@gmail.com <mailto:jsubiavaldez@gmail.com>> An: Pd-List <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> Betreff: Re: [PD] soundfiler alternative? Thank you all.. but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of. the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances. Thanks again On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>[mailto:christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW). > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB. here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6N jEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9) (256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[http s://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ra nMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgc aJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256 380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()] https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%2 9.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwN w-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb5 31e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8 pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/ library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5 HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=% 2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594% 29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems. > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. :-o. time to finally get my dual boot. I weren't so lazy... Christof * IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky) ** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB. > Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr > Von: "IOhannes m zmölnig" <zmoelnig@iem.at <mailto:zmoelnig@iem.at>[mailto:zmoelnig@iem.at <mailto:zmoelnig@iem.at>]> > An: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>[mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>] > Betreff: Re: [PD] soundfiler alternative? > > On 02/27/2017 10:45 PM, Christof Ressi wrote: > >> well, [table] stores the samples as floating point (taking 4 bytes per > >> sample; and 8 byte on 64bit systems), > > It depends on your Pd (32-bit or 64-bit), not on the system. > > well yes, true. > i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. > > > > >> however, there is a simple solution at hand: get youself plenty of RAM > >> and pre-load everything into tables. > >> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw > >> audio, which is probably enough. > > Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory"). > > how much RAM does that machine have? > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) > > but yes, in order to make use of 32GB of memory you need a native 64bit > application (running on a 64bit OS). > > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. > > gmsr > IOhannes > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] https://lists.puredata.info/listinfo/pd-list%5Bhttps://list s.puredata.info/listinfo/pd-list%5D >
_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] https://lists.puredata.info/listinfo/pd-list%5Bhttps://list s.puredata.info/listinfo/pd-list%5D
-- José Rafael Subía Valdez www.jrsv.net <http://www.jrsv.net>[http://www.jrsv.net <http://www.jrsv.net>] _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] https://lists.puredata.info/listinfo/pd-list%5Bhttps://list s.puredata.info/listinfo/pd-list%5D
-- José Rafael Subía Valdez www.jrsv.net http://www.jrsv.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
both Christof's and Jack's solution still create audio drops.
did you actually tweek the parameter?? there *must* be a setting where you don't get dropouts but the question is rather if this setting is acceptable for you.
Gesendet: Dienstag, 28. Februar 2017 um 13:41 Uhr Von: "José Rafael Subía Valdez" jsubiavaldez@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
Okay, update with all the solutions everyone has chipped in. (THANKS AGAIN) both Christof's and Jack's solution still create audio drops. Now I am testing Jean-Yves's patch and seems to do the trick. again, thank you all. If anyone has another idea, I will be interested in looking at other solutions (just for the heck of it). ps. Thanks Jack, I will try changing the [block] cheers On Tue, Feb 28, 2017 at 12:28 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:That's what I meant with:
[soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0.
I know why it happens but it doesn't really matter. Despite its flashy read appearance it's just a warning which can be safely ignored.
The patch itself should work. Tweek the amount of samples per DSP block to find a setting which works for you without dropouts.
On 28.02.2017 12:54, José Rafael Subía Valdez wrote:Hey Christof and Jean-Yves Gratius
Thanks, I am opening them up just now. Christof, your patch gives me these errors when I try it out:
soundfiler_read: truncated to 44100 elements -> this one is repeated by the amount of blocks it will take to completely load the sound file resize failed
any idea why?? (before I start dismantling it?)
Cheers Guys, much appreciated.
On Tue, Feb 28, 2017 at 11:35 AM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at] mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle.
basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms!
note that it needs soundfile_info from iemlib.
[soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0.
Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate).
Hope that helps!
Christof
Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" <jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com] mailto:jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com]> An: Pd-List <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] soundfiler alternative?
Thank you all..
but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.
the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances.
Thanks again
On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at] mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at][mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at] mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
> decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&a...)]] https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29][https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29]]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
> fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
* IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky) ** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
> Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr > Von: "IOhannes m zmölnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at] mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at][mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at] mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]> > An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at][mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]
mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]] > Betreff: Re: [PD] soundfiler alternative? >
> On 02/27/2017 10:45 PM, Christof Ressi wrote: > >> well, [table] stores the samples as floating point (taking 4 bytes per > >> sample; and 8 byte on 64bit systems), > > It depends on your Pd (32-bit or 64-bit), not on the system. > > well yes, true. > i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. > > > > >> however, there is a simple solution at hand: get youself plenty of RAM > >> and pre-load everything into tables. > >> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw > >> audio, which is probably enough. > > Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory"). > > how much RAM does that machine have? > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) > > but yes, in order to make use of 32GB of memory you need a native 64bit > application (running on a 64bit OS). > > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. > > gmsr > IOhannes > > >
> _______________________________________________ > Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D] >
_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D]
--
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net] http://www.jrsv.net[http://www.jrsv.net][http://www.jrsv.net%5Bhttp://www.jrsv.net] http://www.jrsv.net[http://www.jrsv.net]]
_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D]
-- José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net] http://www.jrsv.net[http://www.jrsv.net]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l... --
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Yeah, I tweaked parameters, and actually to follow up on the last message. All of them still cause drops. Some settings more sporadically than others. I have decided to take this process out as I do not have much time to figure out how to solve the problem before having to hand in the score and patch. But I will keep on studying this.
once again thank you all for the help.
cheers
On Tue, Feb 28, 2017 at 1:12 PM, Christof Ressi christof.ressi@gmx.at wrote:
both Christof's and Jack's solution still create audio drops.
did you actually tweek the parameter?? there *must* be a setting where you don't get dropouts but the question is rather if this setting is acceptable for you.
Gesendet: Dienstag, 28. Februar 2017 um 13:41 Uhr Von: "José Rafael Subía Valdez" jsubiavaldez@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
Okay, update with all the solutions everyone has chipped in. (THANKS AGAIN)
both Christof's and Jack's solution still create audio drops. Now I am testing Jean-Yves's patch and seems to do the trick.
again, thank you all. If anyone has another idea, I will be interested in looking at other solutions (just for the heck of it).
ps. Thanks Jack, I will try changing the [block]
cheers
On Tue, Feb 28, 2017 at 12:28 PM, Christof Ressi <christof.ressi@gmx.at [mailto:christof.ressi@gmx.at]> wrote:That's what I meant with:
[soundfiler] will vomit at you in the Pd console but you can simply
ignore it by setting the log level to 0.
I know why it happens but it doesn't really matter. Despite its flashy read appearance it's just a warning which can be safely ignored.
The patch itself should work. Tweek the amount of samples per DSP block to find a setting which works for you without dropouts.
On 28.02.2017 12:54, José Rafael Subía Valdez wrote:Hey Christof and Jean-Yves Gratius
Thanks, I am opening them up just now. Christof, your patch gives me these errors when I try it out:
soundfiler_read: truncated to 44100 elements -> this one is repeated by the amount of blocks it will take to completely load the sound file resize failed
any idea why?? (before I start dismantling it?)
Cheers Guys, much appreciated.
On Tue, Feb 28, 2017 at 11:35 AM, Christof Ressi <christof.ressi@gmx.at [mailto:christof.ressi@gmx.at] mailto:christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]> wrote:
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle. basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms! note that it needs soundfile_info from iemlib. [soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0. Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate). Hope that helps! Christof Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" <jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com] mailto:jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com]> An: Pd-List <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] soundfiler alternative?
Thank you all.. but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of. the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances. Thanks again On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at] <mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>[mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at] mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW). > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB. here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5 d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[ https://msdn.microsoft.com/en-us/library/aa366778(VS.85). aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5 d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()][ https://msdn.microsoft.com/en-us/library/aa366778(VS.85). aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5 d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[ https://msdn.microsoft.com/en-us/library/aa366778(VS.85). aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5 d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()]] https://msdn.microsoft.com/en-us/library/aa366778%28VS. 85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531 e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g%29%28%29[https://msdn.microsoft.com/ en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542& ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=% 2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594% 29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29][https://msdn.microsoft. com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542& ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=% 2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594% 29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28% 29[https://msdn.microsoft.com/en-us/library/aa366778%28VS. 85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531 e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g%29%28%29]]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems. > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. :-o. time to finally get my dual boot. I weren't so lazy... Christof * IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky) ** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB. > Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr > Von: "IOhannes m zmölnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at] <mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]>[mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at] mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]> > An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at][mailto: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]
<mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]>] > Betreff: Re: [PD] soundfiler alternative? > > On 02/27/2017 10:45 PM, Christof Ressi wrote: > >> well, [table] stores the samples as floating point (taking 4 bytes per > >> sample; and 8 byte on 64bit systems), > > It depends on your Pd (32-bit or 64-bit), not on the system. > > well yes, true. > i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. > > > > >> however, there is a simple solution at hand: get youself plenty of RAM > >> and pre-load everything into tables. > >> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw > >> audio, which is probably enough. > > Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory"). > > how much RAM does that machine have? > decent OSs should be able to manage more than a total 4GB of RAM even > when the entire OS is 32bit (a single application will not be able to > address more than 2^32 bytes though; but it should get you closer to > really having 4GB, rather than 2GB) > > but yes, in order to make use of 32GB of memory you need a native 64bit > application (running on a 64bit OS). > > fun fact: on linux, you can use 64bit Pd for >10 years with virtually > all external libraries working. > > gmsr > IOhannes > > > > _______________________________________________ > Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] <mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]>[mailto: Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list][https://lists. puredata.info/listinfo/pd-list%5Bhttps://lists.puredata. info/listinfo/pd-list%5D] https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list%5D[https://lists. puredata.info/listinfo/pd-list%5Bhttps://lists.puredata. info/listinfo/pd-list%5D] >
_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] <mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]>[mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list][https://lists. puredata.info/listinfo/pd-list%5Bhttps://lists.puredata. info/listinfo/pd-list%5D] https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list%5D[https://lists. puredata.info/listinfo/pd-list%5Bhttps://lists.puredata. info/listinfo/pd-list%5D]
-- José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net] <http://www.jrsv.net[http://www.jrsv.net]>[http://www.jrsv.net%5Bhttp://www.jrsv.net] http://www.jrsv.net[http://www.jrsv.net]]
_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] <mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list][https://lists. puredata.info/listinfo/pd-list%5Bhttps://lists.puredata. info/listinfo/pd-list%5D] https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list%5D[https://lists. puredata.info/listinfo/pd-list%5Bhttps://lists.puredata. info/listinfo/pd-list%5D]
-- José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net] http://www.jrsv.net[http://www.jrsv.net ]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] --
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net]
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list]
2017-02-28 9:41 GMT-03:00 José Rafael Subía Valdez jsubiavaldez@gmail.com:
If anyone has another idea
I still think an external is a good/better idea, but looks like it's just me...
I think that is the best idea... glad to help with what I can, but my C skills are very low.
On Tue, Feb 28, 2017 at 3:37 PM, Alexandre Torres Porres porres@gmail.com wrote:
2017-02-28 9:41 GMT-03:00 José Rafael Subía Valdez <jsubiavaldez@gmail.com
:
If anyone has another idea
I still think an external is a good/better idea, but looks like it's just me...
On Die, 2017-02-28 at 12:37 -0300, Alexandre Torres Porres wrote:
2017-02-28 9:41 GMT-03:00 José Rafael Subía Valdez <jsubiavaldez@gmai l.com>:
If anyone has another idea
I still think an external is a good/better idea, but looks like it's just me...
Why do you think that? I, too, believe an external that offloads the 'dangerous' (potentially causing drop-outs) operations to a separate thread would be a desirable solution.
People are just thinking about workarounds since we don't seem to have such an external yet (or do we?).
I absolutely don't buy that determinism narrative that grew strong on this list. If you asked me and if I had the power and capability to design such stuff, I'd break determinism for a lot of things, like dealing with filesystem, networking (fortunately solved), and even DSP graph redrawing (I may be just talking here without a clue what architectural impact this would have). I see no value in upholding determinism in a real time language like Pd. I see no point in emulating an ideal world, when the delta between ideal and real world is experienced so harshly. Emulating an ideal world may make sense for offline rendering, but I doubt that is the main use case of Pd.
;tldr: I'm with you, Alex.
Roman
I totally forgot about [sndfiler]. It's actually a threaded version of [soundfiler].
http://grh.mur.at/software/sndfiler.html
Roman
On Die, 2017-02-28 at 17:05 +0100, Roman Haefeli wrote:
On Die, 2017-02-28 at 12:37 -0300, Alexandre Torres Porres wrote:
2017-02-28 9:41 GMT-03:00 José Rafael Subía Valdez <jsubiavaldez@gm ai l.com>:
If anyone has another idea
I still think an external is a good/better idea, but looks like it's just me...
Why do you think that? I, too, believe an external that offloads the 'dangerous' (potentially causing drop-outs) operations to a separate thread would be a desirable solution.
People are just thinking about workarounds since we don't seem to have such an external yet (or do we?).
I absolutely don't buy that determinism narrative that grew strong on this list. If you asked me and if I had the power and capability to design such stuff, I'd break determinism for a lot of things, like dealing with filesystem, networking (fortunately solved), and even DSP graph redrawing (I may be just talking here without a clue what architectural impact this would have). I see no value in upholding determinism in a real time language like Pd. I see no point in emulating an ideal world, when the delta between ideal and real world is experienced so harshly. Emulating an ideal world may make sense for offline rendering, but I doubt that is the main use case of Pd.
;tldr: I'm with you, Alex.
Roman
how do you download it? couldnt do it
2017-02-28 13:10 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I totally forgot about [sndfiler]. It's actually a threaded version of [soundfiler].
http://grh.mur.at/software/sndfiler.html
Roman
On Die, 2017-02-28 at 17:05 +0100, Roman Haefeli wrote:
On Die, 2017-02-28 at 12:37 -0300, Alexandre Torres Porres wrote:
2017-02-28 9:41 GMT-03:00 José Rafael Subía Valdez <jsubiavaldez@gm ai l.com>:
If anyone has another idea
I still think an external is a good/better idea, but looks like it's just me...
Why do you think that? I, too, believe an external that offloads the 'dangerous' (potentially causing drop-outs) operations to a separate thread would be a desirable solution.
People are just thinking about workarounds since we don't seem to have such an external yet (or do we?).
I absolutely don't buy that determinism narrative that grew strong on this list. If you asked me and if I had the power and capability to design such stuff, I'd break determinism for a lot of things, like dealing with filesystem, networking (fortunately solved), and even DSP graph redrawing (I may be just talking here without a clue what architectural impact this would have). I see no value in upholding determinism in a real time language like Pd. I see no point in emulating an ideal world, when the delta between ideal and real world is experienced so harshly. Emulating an ideal world may make sense for offline rendering, but I doubt that is the main use case of Pd.
;tldr: I'm with you, Alex.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
I guess Martin was more talking about this solution (see patch attached). ++
Jack
Le 28/02/2017 à 12:35, Christof Ressi a écrit :
José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle.
basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms!
note that it needs soundfile_info from iemlib.
[soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0.
Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate).
Hope that helps!
Christof
Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" jsubiavaldez@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
Thank you all..
but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.
the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances.
Thanks again
On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&a...)]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
- IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr Von: "IOhannes m zmölnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] --
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net]
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hello Jack,
thanks for sharing, it still causes audio drops. Does it work for you?
cheers?
On Tue, Feb 28, 2017 at 12:12 PM, Jack jack@rybn.org wrote:
I guess Martin was more talking about this solution (see patch attached). ++
Jack
Le 28/02/2017 à 12:35, Christof Ressi a écrit :
José, I think I have a solution which might work for you. see my
attached patch. it's not a clean abstraction but rather demonstrates the principle.
basically, I spread the loading of the soundfile over several DSP blocks
and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms!
note that it needs soundfile_info from iemlib.
[soundfiler] will vomit at you in the Pd console but you can simply
ignore it by setting the log level to 0.
Anyway, I'm really thinking of turning it into an external because there
some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate).
Hope that helps!
Christof
Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr Von: "José Rafael Subía Valdez" jsubiavaldez@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] soundfiler alternative?
Thank you all..
but I am developing patches that are handed to performers and should
work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.
the computer I am programming this is a iMac from 2007 with 4 gb of RAM.
I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances.
Thanks again
On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at
[mailto:christof.ressi@gmx.at]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
Actually, the average Windows user will have more 32-bit apps than
64-bit apps running on their 64-bit OS ;-).
And most Pd users on 64-bit Windows will have a 32-bit Pd because
Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).
decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
on 32-bit Windows you usually get 2 GB per process - or 3 GB with some
tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.
here are the boring details: https://msdn.microsoft.com/en-
us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID= TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=( 94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en- us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID= TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=( 94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw- Z6NjEgcaJn8pbbYAema89g)()]
I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now.
Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
:-o. time to finally get my dual boot. I weren't so lazy...
Christof
- IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit
(with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.
Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr Von: "IOhannes m zmölnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] Betreff: Re: [PD] soundfiler alternative?
On 02/27/2017 10:45 PM, Christof Ressi wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems),
It depends on your Pd (32-bit or 64-bit), not on the system.
well yes, true. i keep forgetting of abominations like running a 32-bit Pd on a 64-bit
OS.
however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough.
Unfortunately, this is only true for 64-bit processes. A single 32-bit
process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
how much RAM does that machine have? decent OSs should be able to manage more than a total 4GB of RAM even when the entire OS is 32bit (a single application will not be able to address more than 2^32 bytes though; but it should get you closer to really having 4GB, rather than 2GB)
but yes, in order to make use of 32GB of memory you need a native 64bit application (running on a 64bit OS).
fun fact: on linux, you can use 64bit Pd for >10 years with virtually all external libraries working.
gmsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
--
José Rafael Subía Valdez www.jrsv.net[http://www.jrsv.net]
_______________________________________________ Pd-list@lists.iem.at
mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Le 28/02/2017 à 13:23, José Rafael Subía Valdez a écrit :
Hello Jack,
thanks for sharing, it still causes audio drops. Does it work for you?
Yes it works. Try to set the last value in [block~] to 512 (instead of 1024). ++
Jack
cheers?
On Tue, Feb 28, 2017 at 12:12 PM, Jack <jack@rybn.org mailto:jack@rybn.org> wrote:
I guess Martin was more talking about this solution (see patch attached). ++ Jack Le 28/02/2017 à 12:35, Christof Ressi a écrit : > José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle. > > basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms! > > note that it needs soundfile_info from iemlib. > > [soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0. > > Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate). > > Hope that helps! > > Christof > > Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr > Von: "José Rafael Subía Valdez" <jsubiavaldez@gmail.com <mailto:jsubiavaldez@gmail.com>> > An: Pd-List <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> > Betreff: Re: [PD] soundfiler alternative? > > Thank you all.. > > but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of. > > the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances. > > Thanks again > > > On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>[mailto:christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. > > Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-). > And most Pd users on 64-bit Windows will have a 32-bit Pd because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW). > >> decent OSs should be able to manage more than a total 4GB of RAM even >> when the entire OS is 32bit (a single application will not be able to >> address more than 2^32 bytes though; but it should get you closer to >> really having 4GB, rather than 2GB) > > on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB. > > here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()] <https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()]> > > > I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems. > >> fun fact: on linux, you can use 64bit Pd for >10 years with virtually >> all external libraries working. > > :-o. time to finally get my dual boot. I weren't so lazy... > > > Christof > > > * IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky) > ** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB. > > > >> Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr >> Von: "IOhannes m zmölnig" <zmoelnig@iem.at <mailto:zmoelnig@iem.at>[mailto:zmoelnig@iem.at <mailto:zmoelnig@iem.at>]> >> An: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>[mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>] >> Betreff: Re: [PD] soundfiler alternative? >> > >> On 02/27/2017 10:45 PM, Christof Ressi wrote: >>>> well, [table] stores the samples as floating point (taking 4 bytes per >>>> sample; and 8 byte on 64bit systems), >>> It depends on your Pd (32-bit or 64-bit), not on the system. >> >> well yes, true. >> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS. >> >>> >>>> however, there is a simple solution at hand: get youself plenty of RAM >>>> and pre-load everything into tables. >>>> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw >>>> audio, which is probably enough. >>> Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory"). >> >> how much RAM does that machine have? >> decent OSs should be able to manage more than a total 4GB of RAM even >> when the entire OS is 32bit (a single application will not be able to >> address more than 2^32 bytes though; but it should get you closer to >> really having 4GB, rather than 2GB) >> >> but yes, in order to make use of 32GB of memory you need a native 64bit >> application (running on a 64bit OS). >> >> fun fact: on linux, you can use 64bit Pd for >10 years with virtually >> all external libraries working. >> >> gmsr >> IOhannes >> >> >> > >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>] mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] <https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]> >> > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] <https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]> > -- > > José Rafael Subía Valdez > www.jrsv.net <http://www.jrsv.net>[http://www.jrsv.net <http://www.jrsv.net>] > > > _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] <https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]> > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list> > _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>-- José Rafael Subía Valdez www.jrsv.net http://www.jrsv.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2017-02-27 at 21:10 +0100, zmoelnig@iem.at wrote:
On 02/27/2017 07:06 PM, José Rafael Subía Valdez wrote:
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical. Seems like there are still some advantages in use Pd on 32-bit architectures.
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
it is not such a simple thing if you care for deterministic sample-synchronous playback (you personally might not care, but Pd does). however, there is a simple solution at hand: get youself plenty of RAM and pre-load everything into tables. 32GB cost about 250,-€ and will allow you to load approx. 24h of raw audio, which is probably enough. it's not exactly super-cheap, but writing software isn't either.
Unfortunately, dealing with largish tables has its complications two which I thought is exactly because everything is stored as 32bit float, even on 64bit systems.
Roman
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things, including numbers and data structures. since data-structures are stored by reference, a data element in the table must be able to hold a (void*) pointer, which - on 64bit systems - takes 8 bytes. the actual numbers stored in these fields are still only single precision numbers.
Seems like there are still some advantages in use Pd on 32-bit architectures.
which?
Unfortunately, dealing with largish tables has its complications two which I thought is exactly because everything is stored as 32bit float, even on 64bit systems.
well, this depends on what you actually do with the tables. afaiu, the OP was happy with the using tables, only the data-loading was causing dropouts. so the problems with data precision do not apply here.
fgmdasr IOhannes
Just because we are at it.
On w32 I can have long tables but I cant get values beyond 16777216 using [tabread].
Also a simple counter stops there, printing with [makefilename %d]:
print: symbol 16777213 print: symbol 16777214 print: symbol 16777215 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216
Is this also happening on 64bit Pd/OS?
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of IOhannes m zmölnig zmoelnig@iem.at Sent: Monday, February 27, 2017 10:13 PM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler alternative?
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things, including numbers and data structures. since data-structures are stored by reference, a data element in the table must be able to hold a (void*) pointer, which - on 64bit systems - takes 8 bytes. the actual numbers stored in these fields are still only single precision numbers.
Seems like there are still some advantages in use Pd on 32-bit architectures.
which?
Unfortunately, dealing with largish tables has its complications two which I thought is exactly because everything is stored as 32bit float, even on 64bit systems.
well, this depends on what you actually do with the tables. afaiu, the OP was happy with the using tables, only the data-loading was causing dropouts. so the problems with data precision do not apply here.
fgmdasr IOhannes
On 2017-02-27 23:46, Lucas Cordiviola wrote:
Just because we are at it.
it's totally unrelated.
On w32 I can have long tables but I cant get values beyond 16777216 using [tabread].
Also a simple counter stops there, printing with [makefilename %d]:
in general i wouldn't use [makefilename] for such things (you are really not interested in the string representation of values, but instead of the values in their numeric representation).
e.g.
[1677726( | [t f f] | | [+ 1] | | | [- ] | [print]
print: symbol 16777213 print: symbol 16777214 print: symbol 16777215 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216
Is this also happening on 64bit Pd/OS?
this is happening on all single precision builds of Pd. you need double precision to work around the problem.
while single precision indeed takes 32bit per number, and double precision takes 64bit, when we talk about a "64bit Pd/OS" we really mean something unrelated (the size of the pointers).
there has been extensive talk about this, including katjas double-precision Pd in 2007 and my recent attempts on getting double-precision Pd to fly, as presented on the PdCon16.
gamsdr IOhannes
On Mon, 2017-02-27 at 23:13 +0100, IOhannes m zmölnig wrote:
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things, including numbers and data structures. since data-structures are stored by reference, a data element in the table must be able to hold a (void*) pointer, which - on 64bit systems - takes 8 bytes. the actual numbers stored in these fields are still only single precision numbers.
Thanks for the explanation. Sounds wasteful in my ears.
Seems like there are still some advantages in use Pd on 32-bit architectures.
which?
It takes half of the memory to load the same amount of audio files. Or did I misunderstand?
Unfortunately, dealing with largish tables has its complications two which I thought is exactly because everything is stored as 32bit float, even on 64bit systems.
well, this depends on what you actually do with the tables. afaiu, the OP was happy with the using tables, only the data-loading was causing dropouts. so the problems with data precision do not apply here.
Yes, that's true indeed.
Roman
On 2017-02-27 23:50, Roman Haefeli wrote:
On Mon, 2017-02-27 at 23:13 +0100, IOhannes m zmölnig wrote:
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things, including numbers and data structures. since data-structures are stored by reference, a data element in the table must be able to hold a (void*) pointer, which - on 64bit systems - takes 8 bytes. the actual numbers stored in these fields are still only single precision numbers.
Thanks for the explanation. Sounds wasteful in my ears.
wasteful of what?
available bits on your RAM module? sure. code that needs to be maintained? no.
Seems like there are still some advantages in use Pd on 32-bit architectures.
which?
It takes half of the memory to load the same amount of audio files. Or did I misunderstand?
no you understood correctly. but you missed the point, that with 64bit archs you will be able to address 2^32 times the amount of data you can theoretically address on a 32bit arch. and while current machines do not have *that* much memory, they still have enough memory to give you more net-value out of your tables than 32bit machines.
this of course does not apply if you are dealing with legacy hardware or with embedded devices (including the popular Raspberry Pis), because they often do not have more memory than can be addressed with 32bit.
gfmsdr IOhannes
On Mon, 2017-02-27 at 18:06 +0000, José Rafael Subía Valdez wrote:
Thank you Lucas and Ingo,
well. I do need to load a lot of samples if I want them preloaded. Regarding the ram post that you sent, as I understand, that is exactly what table does, as it stores it in RAM (am I right?)
Ingo, if I understand correclty, I need to record the audio from readsf~ into a table. this means that I need to create the record system to avoid clicks (fades in and out). This seams overcomplicated for a simple thing. But it appears to be the only solution for this problem.
thanks .. anyone else?
I missed Ingo's mail and it's apparently also not in the list archive. Probably he responded privately.
Anyway, Miller proposed once a solution with [readsf~], too. The idea was to put it into a re-blocked and upsampled subpatch, so that it would read the file much quicker than real time, but slow enough not to cause dropouts. It's a bit more complicated to program than simply sending a message to [soundfiler], but still easy to do. And you need to figure out what is a good upsampling ratio.
Roman
On 27/02/17 19:06, José Rafael Subía Valdez wrote:
this means that I need to create the record system to avoid clicks (fades in and out).
probably i do not understand the problem correctly: you send the same bang that starts the readsf~-playback to the tabwrite~ which records the sample. it should happen at the same 'logical time'. i never had any problems with clicks etc.
the only real drawback is, that you have to set the maximum samplelength before loading the sample. (the table to which the sample is recorded has to be big enough) it can be resized afterwards though. and it takes time. not very much, if the upsampling is high enough, but for example skipping through a lot of presets with associated samples is a little unresponsive this way...
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
José Rafael Subía Valdez -
Lucas Cordiviola -
martin brinkmann -
Roman Haefeli -
zmoelnig＠iem.at