Hi everybody,
I'm not even certain this is a problem across all operating and sound systems; it certainly is a problem on my setup with OS X. Any sort of file access has the possibility (*probability* on the first access to a given file) of causing audio dropouts. For instance, if I use [tunetof] to load in new scale data, the first time I access a given scale file, there's a dropout. Subsequent accesses of that same file don't seem to cause dropouts.
I currently just switched to PD 0.40.3-extended, but this has been happening for as long as I can remember -- several versions back. Is this behavior common across PD, or just something intrinsic to OS X or my sound hardware?
Also, is it some kind of file caching that's keeping subsequent access to a file from causing dropouts?
Phil Stone pkstonemusic.com
hi phil
afaik, this affects every pd (yet) on every os, since this is due to pd's design. all objects i know, that do fileIO (except the threaded soundfiler), do block pd's processing until they will have finished their task. if you have something like this:
[t b b] | | | [read somefile( | | | [somefilereadingobject] | [print]
the bang will be printed only after [somefilereadingobject] has finished reading the file. you are probably going to say, that this is odd, but that is how pd actually/unfortunately works.
the only way to overcome this issue (beside rewriting pd or writing new objects) is to put everything into ram in advance. i don't know, what kind of files you are reading, but there are quite a few objects, that can read and store textfiles, as there are quite many for soundfiles as well.
if you really don't know in advance, which file you are going to open, then you could probably build some kind of an 'asynchronous' filereader patch, that runs in another (-nrt) instance of pd, that passes the data over a network socket ([netsend]/[netreceive]) to your audio patch/instance. beware, that [netsend] is not dropout safe as well, but as long as you only have the [netreceive] in your audio patch, this won't be an issue.
roman
p.s.: it's probably the right moment now to mention, that the nova project addresses such issues.
On Sat, 2007-10-13 at 12:02 -0700, Phil Stone wrote:
Hi everybody,
I'm not even certain this is a problem across all operating and sound systems; it certainly is a problem on my setup with OS X. Any sort of file access has the possibility (*probability* on the first access to a given file) of causing audio dropouts. For instance, if I use [tunetof] to load in new scale data, the first time I access a given scale file, there's a dropout. Subsequent accesses of that same file don't seem to cause dropouts.
I currently just switched to PD 0.40.3-extended, but this has been happening for as long as I can remember -- several versions back. Is this behavior common across PD, or just something intrinsic to OS X or my sound hardware?
Also, is it some kind of file caching that's keeping subsequent access to a file from causing dropouts?
Phil Stone pkstonemusic.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hi phil
afaik, this affects every pd (yet) on every os, since this is due to pd's design. all objects i know, that do fileIO (except the threaded soundfiler),
Ah, the legendary threaded soundfiler. I tried to track this down once, but had no luck. I remember something about it having a problem with audio files, but I have always wondered if it would (or at least could be made to) work well for non-audio data loads.
do block pd's processing until they will have finished their task. if you have something like this:
[t b b] | | | [read somefile( | | | [somefilereadingobject] | [print]
the bang will be printed only after [somefilereadingobject] has finished reading the file. you are probably going to say, that this is odd, but that is how pd actually/unfortunately works.
I was afraid that this was so. Too bad. I could see it being necessary for audio loads, but non-audio file I/O, at least, should be able to run in the background.
the only way to overcome this issue (beside rewriting pd or writing new objects) is to put everything into ram in advance. i don't know, what kind of files you are reading, but there are quite a few objects, that can read and store textfiles, as there are quite many for soundfiles as well.
Do you know if the caching effect I described (where second and later accesses to files tend not to glitch) work across OSes, and if so, can it be relied upon? I.e., if I load everything I need at least once, will it be ram-cached? I don't know anything about this part of *nix (OS X or other flavors), never mind Windows. I would guess that it probably only helps for small files anyway, because if the load from ram takes long enough, there will still be dropouts.
Does anybody know if ram disks are possible on OS X?
if you really don't know in advance, which file you are going to open, then you could probably build some kind of an 'asynchronous' filereader patch, that runs in another (-nrt) instance of pd, that passes the data over a network socket ([netsend]/[netreceive]) to your audio patch/instance. beware, that [netsend] is not dropout safe as well, but as long as you only have the [netreceive] in your audio patch, this won't be an issue.
That's an intriguing idea. OSC could also probably be used for loading/saving patches and such, though [netsend][netreceive] would be more versatile.
roman
p.s.: it's probably the right moment now to mention, that the nova project addresses such issues.
I hope for great things from that project. An asynch PD would be awesome.
Thanks for writing, Roman.
Phil
On Sat, 2007-10-13 at 12:02 -0700, Phil Stone wrote:
Hi everybody,
I'm not even certain this is a problem across all operating and sound systems; it certainly is a problem on my setup with OS X. Any sort of file access has the possibility (*probability* on the first access to a given file) of causing audio dropouts. For instance, if I use [tunetof] to load in new scale data, the first time I access a given scale file, there's a dropout. Subsequent accesses of that same file don't seem to cause dropouts.
I currently just switched to PD 0.40.3-extended, but this has been happening for as long as I can remember -- several versions back. Is this behavior common across PD, or just something intrinsic to OS X or my sound hardware?
Also, is it some kind of file caching that's keeping subsequent access to a file from causing dropouts?
Phil Stone pkstonemusic.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sat, 2007-10-13 at 17:06 -0700, Phil Stone wrote:
Phil Stone wrote:
Does anybody know if ram disks are possible on OS X?
To answer my own question about OS X ram disks (GIYF), yes it seem to be possible (though not especially well documented). Since most of my files are pretty small, this might help.
Phil
why do you need a ram disk? wouldn't it be sufficient to just read all necessary files in advance? they will be automatically in ram then...
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Sat, 2007-10-13 at 17:06 -0700, Phil Stone wrote:
Phil Stone wrote:
Does anybody know if ram disks are possible on OS X?
To answer my own question about OS X ram disks (GIYF), yes it seem to be possible (though not especially well documented). Since most of my files are pretty small, this might help.
Phil
why do you need a ram disk? wouldn't it be sufficient to just read all necessary files in advance? they will be automatically in ram then...
roman
Do you mean because of disk caching? If not, then it seems fairly complicated to create a whole new all-file-loader/memory structure for each type of file.* The beauty of a ram disk is that it the file addressing is exactly the same. In fact, I just now set one up in a few minutes, and it works wonderfully. I can change sssad presets, or [tunetof] tunings, with nary a glitch. Of course, it won't work for files big enough to take more than one dsp block to load from ram -- that's a big limitation.
- I imagine this working by pre-loading everything in a given directory
(or listed in another file, maybe). Storing, then accessing and copying that information live doesn't seem trivial, to me at least.
Phil
On Sat, 2007-10-13 at 17:44 -0700, Phil Stone wrote:
Roman Haefeli wrote:
On Sat, 2007-10-13 at 17:06 -0700, Phil Stone wrote:
Phil Stone wrote:
Does anybody know if ram disks are possible on OS X?
To answer my own question about OS X ram disks (GIYF), yes it seem to be possible (though not especially well documented). Since most of my files are pretty small, this might help.
Phil
why do you need a ram disk? wouldn't it be sufficient to just read all necessary files in advance? they will be automatically in ram then...
roman
Do you mean because of disk caching? If not, then it seems fairly complicated to create a whole new all-file-loader/memory structure for each type of file.* The beauty of a ram disk is that it the file addressing is exactly the same. In fact, I just now set one up in a few minutes, and it works wonderfully. I can change sssad presets, or [tunetof] tunings, with nary a glitch. Of course, it won't work for files big enough to take more than one dsp block to load from ram -- that's a big limitation.
i see. i was thinking, that oyu might have only very few file reading objects in your patch, that it would be easy enough to adapt your patch in a manner, that it loads all presets in advance. but if you are using an ready-made, more complex system, then this probably won't be an easy thing to do.
nice to hear, that it works with a ramdisk. i never used a ramdisk myself and i didn't know, that it would be so easy to setup.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Am 13.10.2007 um 20:06 schrieb Phil Stone:
Phil Stone wrote:
Does anybody know if ram disks are possible on OS X?
To answer my own question about OS X ram disks (GIYF), yes it seem
to be possible (though not especially well documented). Since most of my files are pretty small, this might help.
a ram disk is quite trivial to do with the disk utility. the question is if it really helps. there was an discussion on this not so long ago:
http://lists.puredata.info/pipermail/pd-list/2007-07/052503.html
m.
Max Neupert wrote:
Am 13.10.2007 um 20:06 schrieb Phil Stone:
Phil Stone wrote:
Does anybody know if ram disks are possible on OS X?
To answer my own question about OS X ram disks (GIYF), yes it seem to be possible (though not especially well documented). Since most of my files are pretty small, this might help.
a ram disk is quite trivial to do with the disk utility. the question is if it really helps. there was an discussion on this not so long ago:
http://lists.puredata.info/pipermail/pd-list/2007-07/052503.html
m.
Thanks for pointing that thread out -- I missed it. I'm experimenting with a ram disk right now, and my preliminary finding is that it works great for me. I'm loading small files (sssad presets and [tunetof] tunings), and have enough ram to make it worthwhile. It has the advantage over disk caching that one doesn't have to do the first load (the one that goes to hard drive) ahead of time.
I bulk-copied all the files I need to the ram disk; I can access them live with no audio dropouts, so far.
Phil
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
Thanks for pointing that thread out -- I missed it. I'm experimenting with a ram disk right now, and my preliminary finding is that it works great for me. I'm loading small files (sssad presets and [tunetof] tunings), and have enough ram to make it worthwhile.
At least for [tunetof] another possible workaround would be to put the scale(s) you want to use into messages in your patch. The scales in [table]-format are just short lists of numbers like "1 1.125 1.25 1.33333333333 1.5 1.66666666667 1.875 2.0" (ptolemy) that fit into a message box easily. Send then to tunetof's last inlet and you're done. Make a scale-switcher abstraction with your favourite scales, and you can even reuse that.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Max Neupert -
Phil Stone -
Roman Haefeli