hi Tim,
I read:
i've been working on a threaded soundfiler, that i've added to the devel_0_37 branch, providing the capabilities of loading / saving arrays on the fly without interrupting the dsp performance.
I just did a fresh checkout of devel_0_37 but I still have dropouts when using soundfiler to load stuff into tables.
but the output looks fine (except for the watchdog barking when loading very large files or switching screens to the pd gui screen):
combat:/home/x/audio/sw/pd/pdevel-0.37# ./bin/pd -rt reading startup file: /root/.pdrc priority 8 scheduling enabled. memory locking enabled. priority 6 scheduling enabled. memory locking enabled. global soundfiler thread launched couldn't open MIDI input device 0 couldn't open MIDI output device 0 opened 0 MIDI input device(s) and 0 MIDI output device(s). priority 1 scheduling for soundfiler. . .
i also added the feature of resizing arrays without clicks by sending a |resize arrayname size( message.
that should be [; arrayname resize size ( shouldn't it ? I enabled this too when ./configuring but still get clicks when resizing.
i've only been able to test it on my linux machine, but since it's more or less posix compatible, it should be possible to compile it for other platforms, too. i still consider it as experimental, but only because i haven't been able to test it on other systems...
I tried it on debian-ppc ,
any iedeas ?
thanks,
x
but the output looks fine (except for the watchdog barking when loading very large files or switching screens to the pd gui screen):
hm ... i found that there is a problem when allocating memory when running in realtime mode ... i'll investigate that later this day ...
i also added the feature of resizing arrays without clicks by sending a |resize arrayname size( message.
that should be [; arrayname resize size ( shouldn't it ? I enabled this too when ./configuring but still get clicks when resizing.
no... pd messages should be processed at the same logical time... if not, there would be no way to syncronize with the rest of the patch. that's why i added this feature to the soundfiler:
|resize arrayname resize( | |soundfiler| | [0]
the soundfiler object is able to perform the operations in the background and signal the patch, when it's done ... to me, this seems to be the best solution...
cheers...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- 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
i've been working on a threaded soundfiler, that i've added to the devel_0_37 branch, providing the capabilities of loading / saving arrays on the fly without interrupting the dsp performance.
I just did a fresh checkout of devel_0_37 but I still have dropouts when using soundfiler to load stuff into tables.
the problem is the memory locking that the realtime mode implies... i don't think that it's a good idea to switch it off ...
i disabled the memory locking before allocating the memory and enabled it after that ... should work now...
cheers...
I read:
I just did a fresh checkout of devel_0_37 but I still have dropouts when using soundfiler to load stuff into tables.
the problem is the memory locking that the realtime mode implies... i don't think that it's a good idea to switch it off ...
didn't work nrt either for me
i disabled the memory locking before allocating the memory and enabled it after that ... should work now...
did a cvs update a few hours ago and it works like a charm now, thanks heaps for the effort.
take care,
x
-
CK -
Tim Blechmann