Hi,

I would like to use [vd~] to create a doppler shift style pitch change, but I am having some problems.

The delay length is calculated on the control level, I don't have the option of calculating it using signal math since this would be too computationally expensive. The problem is that the signal will obviously jump every 1 ms when the control level updates, which creates a horrible ring mod esque effect.

I tried using [line~] from the cyclone pack as follows:

input control value
|\
| \
| \
| [1[
| |
[line~]
|
output delay line length signal

to try and interpolate between the 1ms spaced control values. This seemed to have some benefit but the pitch shifted sounds still sounded pretty bad.

I'm fairly sure this isn't due to aliasing in the delay line because the sound I'm using is resampled to 44.1KHz from 11.025KHz.

Any help would be greatly appreciated.

Ben

i'm not sure, if i understand, which kind of effect you wan't to achieve. do you only wan't to get a doppler effect while changing the delaytime with a slider (or whatever)? or do you want to change pitch permanently? then you'd need a granular synthesis effect, i'd guess. why do you think, it would be too expensive to use a signal source for modulation?

The minimum update rate of [line~] is the block size, which by default in Pd is 64 samples. This is actually about 1.4ms, so your ramps aren't likely as smooth as you think. You might be better off using [vline~], which doesn't conform to block boundaries. But it will still be a linear ramp, so if your modulation source isn't linear, it won't be perfectly accurate. I would also like to know why you can't do this at the signal level.

Also, [line~] is a pure Pd object. [Line~] is the cyclone variant, and I think the only difference is that [Line~] accepts [pause( and [resume( messages.

Thanks for your response.

I don't want to do the calculations at the signal level because the equations are pretty complicated and there are 40 instances of them, I need to save all the computing power I can really.

Thanks for the tip about vline~, that worked perfectly with a line length of 20ms

...but don't forget, there is a "point" (or frequency or refresh-rate) at which calculations via (audio)-signals are faster than the data-wise calculations...

I wonder when this exactly is the case. I have no Mac so I can't directly measure the CPU-load... but using audio often helped to reduce dropouts.

...ANd why or how?! Well, I don't know since I'm not into C-programming or whatever.. But I guess there must be any kind of pre- or post-message sticking to the data-signal (apart from all those "bang", "float" or "list" ) which roughly is left out at audio-signals.
If there is nothing like "audio" for audio-signals (like "bang" for "data-bang"), then the usual premessages like "float", "list"... would suffice.

So in general (looking at just one action like one value of the audio-signal-vector or one "banged data-action") there is more going on at data-signals then at audio-signals.
So they are calculated faster if the data-refresh-rate exceeds a certain frequency. Any other theories?!

Flipp