Hi Miller and all, is there any means (or will there be a possibility in the future) to steer a part of a signal network (e.g. a subpatcher) in a way that it doesn't run in real-time but rather uses the full cpu power available? This would be good for filling large arrays with audio data.
thanks, Thomas
hi Thomas,
- (yet another workaround:) -- with a combination of oversampled
[switch~] and a [bang~] you may set the (logical) speed of dsp processing in a window. This speed may be up to 8192 times the realtime (or more, if [switch~] is dynamically created) -- I think this is sufficient in most cases... test the attachment.
- This reminds me of my old (and rather modest?) proposal for using
Pd in batch processing of sounds stored on disk. The needed changes are: minor editing of Pd's scheduler, and an addition of a startup option.
- ``Filling large arrays with audio data'' is one of the aims of
my vexing library. I can send you the sources, if you wish.
Krzysztof
Thomas Grill wrote: ...
is there any means (or will there be a possibility in the future) to steer a part of a signal network (e.g. a subpatcher) in a way that it doesn't run in real-time but rather uses the full cpu power available? This would be good for filling large arrays with audio data.
#N canvas 168 255 505 276 12; #N canvas 0 0 450 300 graph1 0; #X array t 524288 float 0; #X coords 0 1 524287 -1 200 140 1; #X restore 269 51 graph; #X obj 61 227 tabwrite~ t; #X obj 21 21 bang~; #X obj 21 131 switch~ 524288 1 8192; #X msg 95 56 1; #X msg 21 92 0; #X obj 21 56 t b b; #X obj 24 174 noise~; #X obj 95 21 loadbang; #X connect 2 0 6 0; #X connect 4 0 3 0; #X connect 5 0 3 0; #X connect 6 0 5 0; #X connect 6 1 1 0; #X connect 7 0 1 0; #X connect 8 0 4 0;
Von: Krzysztof Czaja [mailto:czaja@chopin.edu.pl]
- (yet another workaround:) -- with a combination of oversampled
[switch~] and a [bang~] you may set the (logical) speed of dsp processing in a window. This speed may be up to 8192 times the realtime (or more, if [switch~] is dynamically created) -- I think this is sufficient in most cases... test the attachment.
Wow, that is great! Even the sampling rate value in the signal vector is correctly adjusted to sys_getsr()/8192! That should do it for my purposes.
many thanks, Thomas
Hi, another question on that one: Are there any restrictions for the length of a signal vector? Does it have to be even or is there any maximum length?
Thomas
Thomas Grill wrote:
Hi, another question on that one: Are there any restrictions for the length of a signal vector? Does it have to be even or is there any maximum length?
1.) it has to be a power of two there *was* a restriction of the length too (i think 65536 samples), but this has changed to 2^32 (which is more than 27h at 44.1kHz)
2.) regarding up/downsampling: funny enough, just today i noticed a bug bug within the setting of the sample-rate when doing up/downsampling: the sampling-rate is modified the wrong way: if you do upsampling by 2 from 44.1kHz, a sampling-rate of 22.05kHz is reported. the bug is in line 889 of d_ugen.c: diff says:
889c889 < srate = parent_srate * realoverlap * upsample / downsample; /* IOhannes
*/
srate = parent_srate * realoverlap * downsample / upsample; /*
IOhannes */
mea culpa
mfg.csda.dr IOhannes
Thomas
you:
2.) regarding up/downsampling: funny enough, just today i noticed a bug bug within the setting of the sample-rate when doing up/downsampling: the sampling-rate is modified the wrong way: if you do upsampling by 2 from 44.1kHz, a sampling-rate of 22.05kHz is reported.
me:
Even the sampling rate value in the signal vector is correctly adjusted to sys_getsr()/8192! That should do it for my purposes.
*blush* I don't know what i exactly wanted to state with that?!...
For me it's unusable anyway because I'd need the sample rate to have its original value! (no up- or downsampling) Will that be possible somehow? The optimal thing would be a means to decouple a part of the signal network and steer it in my external with my own values for signal vector length and sample rate.
Thomas
hi,
to clarify this a bit: apart from having to be a power of two, and less than 2^31 (not 2^32:-) which is 13.5 hours, it should be possible to be saved in a file as [block~]'s argument. This imposes a maximum of 524288, and this is why I have used 8192 oversampling factor in my example. This restriction may be lifted with (ugly) dynamic creation of a [block~] or [switch~] object.
Krzysztof
Thomas Grill wrote: ...
Are there any restrictions for the length of a signal vector? Does it have to be even or is there any maximum length?
-
IOhannes m zmoelnig -
Krzysztof Czaja -
Thomas Grill