Hi list, I followed some posts around this topic about a year ago... Has this been incorporated in any pd windows binary release? Ive tried standard 0.38 and pd-devel 0.38.4-2 and still get those annoying clicks when loading big files. Or...any other ideas to load a wavefile to an array in background? greg
I followed some posts around this topic about a year ago... Has this been incorporated in any pd windows binary release? Ive tried standard 0.38 and pd-devel 0.38.4-2 and still get those annoying clicks when loading big files. Or...any other ideas to load a wavefile to an array in background? greg
i think, i haven't compiled the devel binary with the threaded soundfiler ... basically because at the current implementation of the arrays, relocating of the array in memory and the resorting of the dsp tree every time you load a new soundfile is not clean at all...
i'm willing to maintain a threaded soundfiler, but not with the current implementation of arrays in pd and the current implementation of garray_getfloatarray(). especially i don't want to rewrite the threaded soundfiler for each new version of pd ...
if there are a number people who want to use a windoze binary with the threaded soundfiler on their own risk, i can release a binary with the threaded soundfiler ... right now, you have to compile from scratch ...
cheers ... tim
It would be easy to make an abstraction that uses readsf~ to load soundfiles into tables...
cheers Miller
On Sat, May 28, 2005 at 06:31:04PM +0200, Tim Blechmann wrote:
I followed some posts around this topic about a year ago... Has this been incorporated in any pd windows binary release? Ive tried standard 0.38 and pd-devel 0.38.4-2 and still get those annoying clicks when loading big files. Or...any other ideas to load a wavefile to an array in background? greg
i think, i haven't compiled the devel binary with the threaded soundfiler ... basically because at the current implementation of the arrays, relocating of the array in memory and the resorting of the dsp tree every time you load a new soundfile is not clean at all...
i'm willing to maintain a threaded soundfiler, but not with the current implementation of arrays in pd and the current implementation of garray_getfloatarray(). especially i don't want to rewrite the threaded soundfiler for each new version of pd ...
if there are a number people who want to use a windoze binary with the threaded soundfiler on their own risk, i can release a binary with the threaded soundfiler ... right now, you have to compile from scratch ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, May 29, 2005 at 01:53:18PM -0700, Miller Puckette wrote:
It would be easy to make an abstraction that uses readsf~ to load soundfiles into tables...
but would not load instantaneous as --threaded-sf until one can run an abstraction non-real-time - processing block-after-block as fast as possible in a lower-priority thread until recieving some kind of explicit stopping mechanism.. (in this case the bang from readsf~)
i personally favor this approach, though i can not offer to write it, since it would not only open up new processing possibilities, but 'readanysoundfiler' would instantly exist as well, supporting FLAC and all the other funky formats..
hi miller
It would be easy to make an abstraction that uses readsf~ to load soundfiles into tables...
actually, this is a very weak workaround ... i mean, loading a 3 minutes sample to a buffer would take about 3 minutes ... a threaded soundfiler would maybe take 3 seconds ...
i think waiting 3 seconds would be acceptable for a performance, but 3 minutes?
writing a clean implementation of the threaded soundfiler wouldn't be that hard and it's a pretty common request, not an exotic feature for a realtime performance system like pd ...
cheers ... tim
Well, actually, you can upsample the readsf~ to choose much faster speeds... however, you do have to wait longer for a deterministic result than you do for a "fast-as"possible" one, such as threading would give you.
On Mon, May 30, 2005 at 01:34:18AM +0200, Tim Blechmann wrote:
hi miller
It would be easy to make an abstraction that uses readsf~ to load soundfiles into tables...
actually, this is a very weak workaround ... i mean, loading a 3 minutes sample to a buffer would take about 3 minutes ... a threaded soundfiler would maybe take 3 seconds ...
i think waiting 3 seconds would be acceptable for a performance, but 3 minutes?
writing a clean implementation of the threaded soundfiler wouldn't be that hard and it's a pretty common request, not an exotic feature for a realtime performance system like pd ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Well, actually, you can upsample the readsf~ to choose much faster speeds... however, you do have to wait longer for a deterministic result than you do for a "fast-as"possible" one, such as threading would give you.
right ... but when upsampling the readsf~ it's much more likely to experience a click (disc bandwidth / cpu) than if you do that asynchronous if there is time ... :-)
cheers ... tim
upsampling 64x times the readsf~ works quite well for me and does what i needed, i get a clean output.
thanks for all the help g
Well, actually, you can upsample the readsf~ to choose much faster speeds... however, you do have to wait longer for a deterministic result than you do for a "fast-as"possible" one, such as threading would give you.
On Mon, May 30, 2005 at 01:34:18AM +0200, Tim Blechmann wrote:
hi miller
It would be easy to make an abstraction that uses readsf~ to load soundfiles into tables...
actually, this is a very weak workaround ... i mean, loading a 3 minutes sample to a buffer would take about 3 minutes ... a threaded soundfiler would maybe take 3 seconds ...
i think waiting 3 seconds would be acceptable for a performance, but 3 minutes?
writing a clean implementation of the threaded soundfiler wouldn't be that hard and it's a pretty common request, not an exotic feature for a realtime performance system like pd ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
-
ggkarman＠musicologia.com -
ix＠replic.net -
Miller Puckette -
Tim Blechmann