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
Does pitch shift ratio vary with clock speed?
Moderator: frank
-
- Posts: 74
- Joined: Mon Sep 11, 2006 10:04 pm
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.
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.
Frank Thomson
Experimental Noize
Experimental Noize
-
- Posts: 22
- Joined: Thu Dec 08, 2011 9:23 pm
- Location: Montréal, Canada
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 ! )
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 ! )
Last edited by Dedjazzgadgetz on Fri Dec 20, 2013 1:48 pm, edited 1 time in total.
Actually it will shorten the latency, give it a try.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 !
Frank Thomson
Experimental Noize
Experimental Noize
-
- Posts: 22
- Joined: Thu Dec 08, 2011 9:23 pm
- Location: Montréal, Canada
Yes, that's what I was getting at by "halving the latency". O.K. cool... actually : great news !
Thanks sooooo much !
Dedjazzgadgetz
Thanks sooooo much !
Dedjazzgadgetz
Last edited by Dedjazzgadgetz on Sun Dec 15, 2013 11:07 pm, edited 2 times in total.
-
- Posts: 22
- Joined: Thu Dec 08, 2011 9:23 pm
- Location: Montréal, Canada
-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
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
Last edited by Dedjazzgadgetz on Fri Dec 20, 2013 1:58 pm, edited 1 time in total.
-
- Posts: 22
- Joined: Thu Dec 08, 2011 9:23 pm
- Location: Montréal, Canada
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
...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