Re: [PD] Is asynchronous but fast loading possible?
Hmm, what would it take to change/fix this? This is part of the reason I can only use PD in the studio, and not live... Sounds like there is a need for some kind of better cross-platform soundfile player external. This might be PD's biggest weakness for audio use! Maybe Georg's [sndfile] would help but his post didn't give any info on what it does. ~D On 3/6/07, Tim Blechmann [EMAIL PROTECTED] wrote: On Tue, 2007-03-06 at 16:30 +0100, Matteo Sisti Sette wrote: So my question is. Is there an asynchronous, non-blocking way to load a wave file into a table, but faster than real-time playing? I mean, something that loads the file as fast as it can but without blocking dsp execution, and for example bangs when load is complete? short answer: no long answer: it's a bit better with my sndfiler, but the answer is still no ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is asynchronous but fast loading possible?
David Powers wrote: Maybe Georg's [sndfile] would help but his post didn't give any info on what it does. it is originally by tim, but georg ported it to vanilla pd. and it is a threaded soundfile reader. mfga,.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is asynchronous but fast loading possible?
Hallo! Maybe Georg's [sndfile] would help but his post didn't give any info on what it does. it's not by me ... And the problem with it is, that altough the reading of the soundfile is threaded, the dsp chain needs to be recompiled, which can cause audio dropouts when you have big patches ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is asynchronous but fast loading possible?
On Tue, 2007-03-06 at 17:18 -0600, David Powers wrote: Hmm, what would it take to change/fix this? This is part of the reason I can only use PD in the studio, and not live... Sounds like there is a need for some kind of better cross-platform soundfile player external. This might be PD's biggest weakness for audio use! you can search the archive for the technical problems ... i've posted them several times ... but imho, the problems are less technical. it would require the pd developers to distinguish between a solution, a workaround and a bad hack. my sndfiler is just a bad hack. however if bad hacks or workarounds are praised as a solution there will never be real solutions! personally, i only use the sndfiler, because it uses libsndfile and thus supports more file formats. it's not clickfree with my performance patch, as the used pd api is not scalable ... luckily, there will be other options soon (http://tim.klingt.org/pnpd) cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Most of the trouble in this world has been caused by folks who can't mind their own business, because they have no business of their own to mind, any more than a smallpox virus has. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is asynchronous but fast loading possible?
Hi, Well, I still have to look at the [sndfile] everyone is talking about, but anyway, with regard to the general discussion about sound playing and loading, please let's distinguish between two completely different problems: -PLAYING audio files (i.e. reading them in real time) -LOADING audio files (storing them into a table). [readsf] is for playing. In my opinion its only flaw is that you never know exactly how much you have to wait before you send it a [1( in order to be able to trust on its output. A fix would be an outlet that bangs when the buffer is full or something like that.. Or even something more sofisticated, such as being able to know at any time how much of the buffer is full - so one may have a bigger buffer for security, but start playing when a smaller portion is full. obvioulsy I'm talking of an object that wouldn't be called [readsf]. It would be marvallous to have an object capable of *immediately* start playing, but I suppose that loading a sufficient portion of a file in a 1/44100 of a second is impossible in most platforms, or isn't it? [soundfiler] is for loading. Its limit is that it blocks everything untill it finishes loading. Reading a file in realtime is NOT an alternative. The alternative would be an object capable of threaded loading, but still, loading as fast as possible, not reading at a certain realtime speed; and banging when finished. I dunnow if [sndfile] is such an object but I suppose it isn't since it has been said to be a bad hack and not to be the solution to my problem however I'll have a look at that. Hope I've not been too pedantic, but I had the impression that the problems of playing and loading were a bit mixed up, and I thing it's key to distinguish them or a solution is far to come. Talking about PLAYING (real time reading): it would be grate to be able to override the sample rate of the file (or read it at a given speed, which is the same in this context) which afaik from documentation, is not possible with readsf. Even varying playing speed during playing would be desirable Bye M. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is asynchronous but fast loading possible?
Hallo! [soundfiler] is for loading. Its limit is that it blocks everything untill it finishes loading. Reading a file in realtime is NOT an alternative. The alternative would be an object capable of threaded loading, but still, loading as fast as possible, not reading at a certain realtime speed; and banging when finished. yes, that's what sndfiler does ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Is asynchronous but fast loading possible?
Hi all, This is not related to the reading big sound files thread, although that made me remember of this question I have been wanting to ask for a long time. I know two ways of reading sound files in PD. One is loading them into a table with [soundfiler], and the other is playing them realtime from disk with [readsf]. Readsf is ok for playing big files in realtime without loading the whole of them into ram, and also, it does not block dsp processing while loading. The problem is you can't jump to any point of the file in an instant: you have to allow for a few millisecond to fill the buffer or you'll hear clicks; not to mention you can't do much more than just playing, or if you want to read a chunk of file into a table, you will have to do it at 1x speed. Soundfiler, if you don't load huge files and/or have sufficient ram, is ok... ...as far as you don't need to use it during performance!! Being synchronous, it will block dsp processing for the time necessary to read the whole file, so you have to pre-load all waves before you start performing... So my question is. Is there an asynchronous, non-blocking way to load a wave file into a table, but faster than real-time playing? I mean, something that loads the file as fast as it can but without blocking dsp execution, and for example bangs when load is complete? Thanks in advance M. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Is asynchronous but fast loading possible?
Hallo! short answer: no long answer: it's a bit better with my sndfiler, but the answer is still no well, it depends ... try out sndfile (in pd-cvs/externals/tb/sndfiler) LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
