oops.. i actually use readsf~, which i think is bundled in 0.36?
regarding a "threaded version of soundfiler", i believe that's what readsf~ is supposed to be? see: http://www.akustische-kunst.org/puredata/
the question remains though, what if you just have to play back the tail end of a wav file? right now i have to wait for readsf~ to stream in the whole thing ... i suppose there are offset commands and whatnot, but it seems like a real hassle, atm.
awsome, i'm glad to stand corrected on this one ;) i'll have to play with sfread~ then :)
eskogen@usfamily.net wrote:
i've used Pd for interactive performance quite a bit in the past six months and this was one of the most irritating problems. my solution was to have a series of tables loaded at the start with the first few samples i needed, sized to be very large.
i then had an abstraction to sfread~ any sounds i wanted to load later on into the arrays. sfread~ is threaded, so it doesn't lock up the GUI and audio cause dropouts. this would stream my samples into the array, then let me know when the samples was streamed completely. as long as my tables were large enough, it was no problem.
AFAIK there is no way around it for now, if i were you i would just preload all the samples you may want to use each into its own array and then at performance time choose which array you read from. how well this will work out of course depends on how many samples you need.
-josh
Matthew Nish-Lapidus wrote:
=
hi,
has any one come up with a solution to the problem of audio dropouts when loading wav files into tables? i'm going to be doing some performance soon, and i'd really like to be able to load these samples without getting dropouts.
------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-- ____________________________________________________ independent u.s. drum'n'bass -- http://vitriolix.com
------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------
what happened to the threaded verison of soundfiler that's on that same site? it's an old version of pd, is there any way somebody could update 0.36 with the threaded soundifler?
m@. www.ekran.org
----- Original Message ----- From: eskogen@usfamily.net To: "Josh Steiner" josh@vitriolix.com Cc: pd-list@iem.kug.ac.at Sent: Wednesday, February 26, 2003 2:53 AM Subject: Re: Re: [PD] audio dropouts when loading samples
oops.. i actually use readsf~, which i think is bundled in 0.36?
regarding a "threaded version of soundfiler", i believe that's what
readsf~ is supposed to be? see: http://www.akustische-kunst.org/puredata/
the question remains though, what if you just have to play back the tail
end of a wav file? right now i have to wait for readsf~ to stream in the whole thing ... i suppose there are offset commands and whatnot, but it seems like a real hassle, atm.
awsome, i'm glad to stand corrected on this one ;) i'll have to play with sfread~ then :)
eskogen@usfamily.net wrote:
i've used Pd for interactive performance quite a bit in the past six
months
and this was one of the most irritating problems. my solution was to
have
a series of tables loaded at the start with the first few samples i
needed,
sized to be very large.
i then had an abstraction to sfread~ any sounds i wanted to load later
on
into the arrays. sfread~ is threaded, so it doesn't lock up the GUI and audio cause dropouts. this would stream my samples into the array, then let me know when the samples was streamed completely. as long as my
tables
were large enough, it was no problem.
AFAIK there is no way around it for now, if i were you i would just preload all the samples you may want to use each into its own array and then at performance time choose which array you read from. how well this will work out of course depends on how many samples you need.
-josh
Matthew Nish-Lapidus wrote:
=
hi,
has any one come up with a solution to the problem of audio dropouts
when
loading wav files into tables? i'm going to be doing some performance
soon,
and i'd really like to be able to load these samples without getting dropouts.
------ http://USFamily.Net/info - Unlimited Internet - From
$8.99/mo! ------
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-- ____________________________________________________ independent u.s. drum'n'bass -- http://vitriolix.com
------ http://USFamily.Net/info - Unlimited Internet - From
$8.99/mo! ------
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Matthew Nish-Lapidus schrieb:
what happened to the threaded verison of soundfiler that's on that same site? it's an old version of pd, is there any way somebody could update 0.36 with the threaded soundifler?
As you noticed it was a patched pd 0.35 test 26. But the zip contains the changed sources from Yves and maybe it's possible to apply the same changes to the current version of Pd. I haven't tried to do so because the changes did not solve the problem of audio dropouts completely.
Regarding readsf~, it uses a (small) circular buffer, that's why there is some delay. But it's on the other hand the only way to get threaded externals to work. With something like [readsf~ 2 64] for example one would get 64k buffer for each of the two channels. The default is 256k.
Olaf
what happened to the threaded verison of soundfiler that's on that same site? it's an old version of pd, is there any way somebody could update 0.36 with the threaded soundifler?
As you noticed it was a patched pd 0.35 test 26. But the zip contains the changed sources from Yves and maybe it's possible to apply the same changes to the current version of Pd. I haven't tried to do so because the changes did not solve the problem of audio dropouts completely.
Regarding readsf~, it uses a (small) circular buffer, that's why there is some delay. But it's on the other hand the only way to get threaded externals to work. With something like [readsf~ 2 64] for example one would get 64k buffer for each of the two channels. The default is 256k.
as far as i could follow your conversation, readsf~ seams to be a threaded soundfiler.
but: doesn't readsf~ play back and soundfiler write sounds into buffers? i don't know much about the source code of these two objects, but to me they seem to be quite different objects. ...well, i hope that i am wrong :-)
Tim mailto:TimBlechmann@gmx.net ICQ: 96771783 http://www.nyds-exp-discogs.tk -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
Tim Blechmann schrieb:
as far as i could follow your conversation, readsf~ seams to be a threaded soundfiler.
but: doesn't readsf~ play back and soundfiler write sounds into buffers? i don't know much about the source code of these two objects, but to me they seem to be quite different objects. ...well, i hope that i am wrong :-)
Your're not wrong. soundfiler loads files into arrays (and thus has to read soundfiles faster than realtime), readsf~ plays soundfiles in realtime (and is threaded, whereas soundfiler [in the 'normal' pd version] is not).
The fact that an 'ideal' soundfiler would write a complete file in no time into an array makes it so difficult to code. In pd every action performed by an external (that is not threaded) has to fit into one dsp cycle (i.e. usually 64 samples = the blocksize). Reading a soundfile usually takes longer, that's where the dropouts come from. And the longer the file the longer the dropouts...,
I think the confusion in my last mail was caused by the fact I tried to answer two not-that-much-related questions in one single mail.
Olaf
as far as i could follow your conversation, readsf~ seams to be a threaded soundfiler.
but: doesn't readsf~ play back and soundfiler write sounds into buffers? i don't know much about the source code of these two objects, but to me they seem to be quite different objects. ...well, i hope that i am wrong :-)
Your're not wrong. soundfiler loads files into arrays (and thus has to read soundfiles faster than realtime), readsf~ plays soundfiles in realtime (and is threaded, whereas soundfiler [in the 'normal' pd version] is not).
The fact that an 'ideal' soundfiler would write a complete file in no time into an array makes it so difficult to code. In pd every action performed by an external (that is not threaded) has to fit into one dsp cycle (i.e. usually 64 samples = the blocksize). Reading a soundfile usually takes longer, that's where the dropouts come from. And the longer the file the longer the dropouts...,
well, what about reading the data to a temporary array that is completely independant from the pd dsp process and when the complete file has been read, it is copied to the destination array. would that be a possible way?
tim
-
eskogen＠usfamily.net -
Matthew Nish-Lapidus -
Olaf Matthes -
Tim Blechmann -
TimBlechmann＠gmx.net