Added a little [cipher] external to the rfpg library to allow you to encode and decode plain text against a keyword. v0.2 should be available from Deken shortly. Enjoy!

This video is kinda old but it gets the point across. I need to make better helper patches.

It's updated now. Thanks!

Or here
https://puredata.info/Members/ricky/software/rfpg/0.1/

That's super cool.

I pushed an update with intel but it's still showing the older version? How long does it take to catch up or do I need to remove a prior commit somehow?

Pushed intel as well for macOS. Here's the lib for those who want to try it out now.

rfpg.zip

I wrangled my externals into one library of sorts. You can grab rfpg from Deken for macOS for the moment.

Includes:

• audio-rate ambisonics externals
• time-domain granular sampling external
• tonal pitch space model for an incoming sequence of MIDI pitch data
• tape delay synth
• fibonacci rhythm generator
  
  More later!

Yep! Simple enough.

Thanks for the link!

How does one submit a library via Deken? What is the process?

Sorry. Totally missed this. All good?

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.0-rc.5

I thought the cosine shape was really just convenience given that [cos~] is available and that allows for a sample-accurate solution that doesn't involve reading from a table.

@whale-av 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)."

@whale-av 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.

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.

@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.

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 the R in the math.

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?'