Spin Semiconductor

Hi all,

I know that some people have created variable speed clock devices with the FV-1, which would be a great way of having a "size" control. My question is, if you have a pitch shifter in your code, will the shift amount vary with the clock speed?

Thanks,

Sean

Short answer is no, if you look at page 8 of http://www.spinsemi.com/Products/appnot ... N-0001.pdf you will see the pitch shift equations are independent of sample rate.

Now if you change the sample rate while a pitch shift is happening you will hear a transient change in pitch shift amount as the data in the buffer that was read in at the old sample rate is played shifted relative to the new sample rate but once the old data is gone from the buffer the shift amount will be the same again.

Thanks Frank!

Hi Frank & everyone, of course !

Wondering about this: would a faster FV-1 clock -say, doubled (I know: not recommended) half the latency in a pitch shifter ? Guessing probably not, but... here's hoping !

Dedjazzgadgetz
(It's been a long time... family, job, life, the works ! )

Dedjazzgadgetz wrote: Wondering about this: would a faster FV-1 clock -say, doubled (I know: not recommended) half the latency in a pitch shifter ? Guessing probably not, but... here's hoping !

Actually it will shorten the latency, give it a try.

Yes, that's what I was getting at by "halving the latency". O.K. cool... actually : great news !

Thanks sooooo much !

Dedjazzgadgetz

-Oops, just now thinking about this, Frank...

Wouldn't we just be running back into the intrinsic problem of real-time pitch-transposing:

-> Shorter delay mem/faster clock = lower freq. input signal not correctly transposing ? (so, just choose a larger mem size and... -D'oh! more latency... )

from : http://www.spinsemi.com/forum/viewtopic.php?p=1638#1638
-"You can use a shorter delay length (assuming you are not already using the shortest one) but you will lose shifting of lower frequencies. This is due to the fact we are using a buffer to hold the data and playing it back faster than the data is entering the buffer."

With a faster clock, we WILL have shorter latency... yet, still at the expense of low freq. transposing quality... I guess ?

Dedjazzgadgetz

You are correct, there is always a tradeoff.

Darn ! Physics...

...oh well, at least we now have an additional latency workaround at our disposal, if needed (like donstavely's uber-brilliant ramp offset trick from http://www.spinsemi.com/forum/viewtopic.php?p=1506#1506 check EDIT below ! )

Thanks again, Frank : you'z the man !

Dedjazzgadgetz

-> EDIT ! : well, unless donstavely comes forward fleshing-out the inner workings of his mechanism a little more (probably entirely s/w generated Ramps & Crossfades, I'm guessing...eating-up a fat lot of the instruction mem.), we'll have to conclude that (fiddlin' with internal RMPs ) it's not a functional latency workaround ; check-out Frank's take on the subject http://www.spinsemi.com/forum/viewtopic.php?p=2256#2256 ... oh well