hi all
I am attempting to use a phasor~ linked to a threshold~ unit to generate high frequency bangs to then trigger a reasonably complex sample playback mechanism, attempting to mimic granular synthesis. The problem is that when i bring the phasor frequency up into the range of audible pitch, say above 100hz, i can hear a low frequency cyclical shift in the sound texture, which theoretically should be completely even.
So, my question is this: how do non-signal objects function when your trying to use them at signal rates? I.e., what happens in a "threshold~ 0.9 0 0.1 0" object when your giving it a phasor signal that is perhaps 500hz, or in a "route" object with inputs coming at these frequencies? Is there a way to set the non-signal and signal object speeds to be equal? (in CSound, this is equivalent to setting KR to SR, and KSMP to 1). I have a hunch that what is happening is a kind of artefact of the slower speed of the non-signal objects, that somehow a bang or two is getting held over to another processing chunk or something...
any input would be highly appreciated.. thanks! josh whiting, hampshire college jsw98@hampshire.edu
I am attempting to use a phasor~ linked to a threshold~ unit to generate high frequency bangs to then trigger a reasonably complex sample playback mechanism, attempting to mimic granular synthesis. The problem is that when i bring the phasor frequency up into the range of audible pitch, say above 100hz, i can hear a low frequency cyclical shift in the sound texture, which theoretically should be completely even.
Seems like just using metro for triggering would accomplish the same thing.
I believe that control messages can only be processed on vector endpoints - i.e. the finest possible resolution is about 1.4 milliseconds with a 64-sample dsp vector... someone please correct me if I am wrong.
This means that the theoretical maximum rate of reliable triggering is ~689 events per second -- although jitter will probably arise at significantly slower speeds... in fact you are guarenteed to have jitter if the frequency of triggering is not an integer submultiple of the vector-processing speed.
However this is not to be confused with the behavior of the clock when using delays, qlists, metros, etc - where you can schedule events to the millisecond at 64-bit floating point accuracy--- see the pd documentation for the details on this.
For granular synthesis try using the output of phasor~ directly to control the playback operation.. i.e. use phasor~ to drive tabread~. Then convert all parameters to signals and use samphold~ to achieve sample-accurate control.... all in the signal domain. I believe that this method will be less computationally expensive also.
Since phasor~ cannot take signal input for phase I've considered using sample-delays to implement accurate phase shifts for very small grain windowns (untested theory). The other options are to do tricky stuff with the block size and overlap or use some completely different method like convolution (also untested ideas for me).
andy
"Andrew W. Schmeder" wrote:
The other options are to do tricky stuff with the block size and overlap or use some completely different method like convolution (also untested ideas for me).
not that tricky:
|block~ 1|
should exactly give you what you want: control_rate:=dsp_rate 2 things: a) if you want access to the adc~/dac~, you will have to do it in a subpatch (nona: as with all uses of the block~ object) b) most signal-routines have optimized loop-kernels (and therefore doing some more or less nasty things outside the loop-kernel). performance will be significantly worse
mfg.casd.sr IOhannes
-
Andrew W. Schmeder -
IOhannes m zmoelnig -
Josh Whiting