
ricky
I don't have a great answer but it made me wonder if you've seen William Brent's new project OUTPUT? https://github.com/wbrent/OUTPUT
I believe he's using JackTrip to jam online.
https://github.com/jacktrip/jacktrip/releases/tag/v1.4.0rc.5 
ricky
I thought the cosine shape was really just convenience given that [cos~] is available and that allows for a sampleaccurate solution that doesn't involve reading from a table.

ricky
@whaleav said:
@katjav gave it a lot more thought here........ https://www.katjaas.nl/pitchshift/pitchshift.html
I could be wrong but I don't see why the samplerate would be part of the calculation (it isn't)...... as all variables are relative.I was confused because R represents sample rate earlier in the text.
"If the frequency of the sawtooth wave is $f$ (in cycles per second), then its value sweeps from 0 to 1 every $R/f$ samples (where $R$ is the sample rate)."

ricky
@whaleav said:
@ricky It's [ 1] because the exponent of 0 (no shift) is 1 but the tape head has to be stationary (no rotation = 0) for playback at normal speed......
Ah, thanks. That makes sense. Thanks, David.
And [* 1] because (although it seems wrong until you really think about it) the tape head has to be turning backwards relative to the tape (negative values for [phasor~]...) for the pitch to increase (positive transposition values).
There is no point arguing with the patch because it works as expected.......Who is arguing? This was my understanding.
[cos~] windows the output so that amplitude sums are "sort of" ok (with the in and out of phase bits) and the vertical edge of the [phasor~] saw is declicked.
Yes, a nicely scaled fade in and out.

ricky
Cocktail hour is the best hour. Good man and good catch! I totally forgot about the 0.001 multiplier and of course it factors it out. D'oh. As for the [* 1], I thought this made sense in the context of the Pd patch given the positive ramp of the phasor and without it the pitch transposition step is inverted.
What you're saying is that the algebra below is incorrect? Maybe it has something to do with the way the transposition factor is calculated?
It's too early for a cocktail here. Still on my first coffee.

ricky
@jameslo  I remembered this live granular synthesis example from the Pd tutorial website which makes sense to me.
The transposition factor is handled as
pow(2, t/12)  1 * 44100/s)
where t is the transposition step and s is the windows size. Maybe we can reconcile the differences and figure out how Miller factor the sample rate. 
ricky
So, you're saying the
1
is in place to ensure we get decreasing delay amounts for when we want to pitch up and increasing delay amounts when we want to pitch down because of the nature of phasor~? That makes sense but it doesn't explain theR
in the math. 
ricky
Cool. Thanks, @jameslo.
So, getting to the Pitch Shifter example itself, it's easy enough to follow the transposition factor from the math to patch but I'm wondering why the 1 preceding the tape head rotation frequency isn't the current sample rate, as per the math?
f = (t  1) * R / s
I see where one is subtracted from t and where the window size is divided into that but why does R = 1? Is this some other interpretation of 'sample rate?'

ricky
Ah! So
d[n]
is basically the distance between the original input signal (no delay) and the variable delay.So the output sample here would be at the origin diagonal at the bottom of the blue vertical line as you've drawn it?
Would I be correct in saying that the variable delay line is pitching down at that intersection in the illustration you've modified?
I'd still love to know if when sample points in the diagram above are representative of a decreasing delay line time over each period and if there is continuity between each ascending sample (which would pitch shift our input signal up, as I understand it?) this would lead to a continuous pitch shift? My intuition says yes but it's fun to talk about these things, I think.
I guess that's what Miller means by, "If
d[n]
does not change with n, the transposition factor is 1 and the sound emerges from the delay line at the same speed as it went in. But if the delay time is increasing as a function of n, the resulting sound is transposed downward, and if d[n] decreases, upward." 
ricky
@jameslo  actually one small followup from your comment about the index via
nd[n]
. I guess I am not sure how that would be read graphically. I get that we arrive at a new index value through subtraction but where doesn
intersect on this graph? Where doesd[n]
intersect? Hopefully that question makes sense. It might help to plug in some values. 
ricky
@jameslo, Thanks! It is super helpful to talk through it with someone else. My understanding is aligned with yours. I am relieved The parallel line description is precisely where I had arrived when reading through this material, so thanks for confirming. I have some followups so hopefully you're game to keep the conversation going. I am looking at the pitch shifting page.
This graphic is a bit confusing to me, too. Or at least I'm not sure if I am reading it correctly.
How does the vertical line above each point actually relate to enveloping? Additionally, I am unsure how their trajectory actually results in a continuous pitch shift. In this illustration, I think the sample points are representative of a decreasing delay line time over each period and if there is continuity between each ascending sample (which would pitch shift our input signal up, as I understand it?) this would lead to a continuous pitch shift?
I'm trying to understand more clearly how these graphics actually relate to the idea of Momentary Transposition as it's described in the book.

ricky
I've never really dug into pitch shifting before and I have started looking at Miller's pitch shifting patch example from his book but I'm a little confused by the graph in this related example, specifically Fig 7. 17. (I think just because how the qualifying text is worded). I have a few clarifying questions so hopefully someone can humor me.
 The diagonal line from origin (0,0) is the input signal; the dotted line is the variable delay line; the diagonal line at D is the delay line over time relative to the input signal, yes?
 D is the distance from the origin point to the point marked D on the x axis, correct? This is the max length of the delay line?
 The y axis shows the quantity
n  d[n]
whered[n]
represents the delay in samples and this is where I get a bit fuzzy: graphically, what is the output sample here? Why am I subtracting? What am I subtracting?
Thanks in advance!

ricky
This also fixed a related error that cropped up in Audacity, too. This 'solution' makes little sense to me.

ricky
@danielsomar  you're not wrong. I had some development plugs from a friend on my machine. I deleted those and that solved the issue. In my case, the issue was some AU devices.

ricky
Hi @coco. Your solution fixed my problem. This isn't ideal but Pd is working the way it should. How do we repair/reset/amend user privileges on our existing user accounts, I wonder? I flagged this with Miller.



ricky
Yes, no matter what I/O configuration. I get this error consistently. I reported it to the list and I think the devs are incorporating a change;