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