Another approach is to design the implementation around the requirement.

You want to be able to produce a specific frequency. So... make frequency the input parameter, rather than metro time interval.

You want to step through array values, with an equal amount of time for each. That suggests a linear ramp, with a given frequency... i.e., phasor~.

phasor~ always goes 0.0 - 1.0. With 12 points, the array indices go 0.0 - 11 -- but here, note that if you say 0.0 - 11.0, then index 0 covers a span of 1, but index 11 covers a span of 0! That doesn't sound right. Instead, define the span for each index as i <= x < (i+1) -- inclusive at the bottom, exclusive at the top. Now the entire range is 0 <= x < 12... leading to the idea of multiplying the phasor by 12 (number of points).

The array indexing should truncate away any fractional part: if (phasor * 12) = 3.546, it should just read 3. Fortunately, this is the normal behavior of tabread~ (not tabread4~).

So we can get a sample-and-hold waveform this way. (The third array is just showing the floor-ed indices, to demonstrate that tabread~ really is truncating rather than rounding.)

All that's left is to add linear interpolation. A standard way to do linear interpolation is:

x = crossfade factor (0.0 - 1.0)
a = value when x = 0
b = value when x = 1

xfade = (b-a) * x + a (this is a reduction of (a * (1-x)) + (b * x)).

If i is the index, then a = array "at" i, and b = array "at" i+1 -- but here, b needs to be modulo-wrapped back around, because i+1 could be 12-point-something. Pd vanilla doesn't have [%~] at signal rate, but [expr~] has fmod().

So we can index the two values, subtract, multiply by the crossfade factor (which is phasor * 12 --> wrap~), then add the "array[i]" value back in.

23-0408-linear-gendy-2.pd

Now you can do whatever frequency you want, without the awkward conversion. Doesn't matter what that online tutorial said, IMO this fits the stated requirement better.

hjh

I would test Pd by recording a few seconds of [phasor~ 1], and measuring the number of samples per cycle. Obviously this should be the system sample rate, give or take floating point rounding error.

The worry in this thread is that Pd is playing at the wrong speed.

The only way this could happen is if [phasor~ 1] is running at the wrong speed, because in the demo patch, phasor~ is the only thing controlling the speed.

Therefore, if there is no evidence of phasor~ running at the wrong speed, then Pd must be playing the file at the true speed!

"But what if the system sample rate differs from the file's?" The file is at the lowest sample rate in common use. If Pd is playing it slower than Audacity, then Pd would have to be running below 44.1 kHz, which is unlikely to be supported in hardware. So I'm comfortable ruling that out (not to mention that scaling the phasor~ by the file's number of samples already accounts for this). Common scenario would be: 44.1 kHz file, 48 kHz system SR, without correcting for this then Pd would play faster, but that isn't the report.

is audacity running at 44100?

I'm pretty sure Audacity has no power to override the hardware sample rate. I've never heard of soundcards issuing separate, per-app interrupts at different rates (imagine how difficult that would be, to make it work, highly implausible). AFAIK Audacity does sample rate conversion when the file is at a different rate from the hardware... just like all other audio software.

Is it 100% guaranteed that Audacity is playing it at the right speed?

hjh

@KMETE If you stop the [metro] then the cloned players will eventually stop as the [ine~] objects reach their "end".
A reset of the [phasor~] by a 0 to its right inlet will restart the [phasor~] at 0 .... but [phasor~] is always running at its set rate.
So you need to send the 0 to [phasor~] and bang the [snapshot~] immediately afterwards......but only once your time "x" has elapsed.
In your patch that should start the "next" clone at the start of the array.
David.

Hey @whale-av and anyone else interested in this issue.

I'm still trying to wrap my head around this.
So this looper works if you loop one pass and play it. It works with overdubbing at speed = 1 or -1.. The problem is if you overdub at any speed other than 1 or -1.

I am going to explain the issue as I see it, although I may be mistaken. It is set up so the buffer length will not change after the first recording, so when overdubbing the buffer size doesn't change. If you doing playback at a speed other than 1 or -1 the speed of the phasor~ reading the array with the loop will change to that new speed. When you are done overdubbing, it would seem that the phasor~ should be at the same speed it was during the overdub, but if this is the case things get out of whack. At least that was my observation in the "simple3.pd" patch a few posts up.

I added an [expr] object to try and accomodate for what I was hearing. But now what is happening is it seems that the loop is getting shorter if it is less than 1 and it's too long if it's greater than 1.

I must be missing something obvious here.

I haven't tried this yet, but maybe I should add another phasor~ that is lined up to start with the first phasor~ playing the array, but when I alter playback speed this 2nd phasor will change as well and i can use that to start and stop the overdub process. What I am hearing is the overdub, when playing at speed = 2, will double in speed , then double in speed again during a recording. and the opposite is true for half speed. I think maybe a 2nd phasor can modulate to the new speed when an overdub is activated then take over reading the array when an overdub is finished. It's just an idea I had.

Anyway, any suggestions into this would be much appreciated.
Here is what I have now. simple6.pd

Thank you.

@gentleclockdivider Does sending a start at the same time to the [metro] left inlet help?
Between the green [/ 3] and the left inlet of the blue [metro] put the message [1 $1(
The parts of the message are distributed across the inlets of the [metro] so you know it gets them at the same time.
Disconnect the direct cord between [/ 3] and the right inlet of the [metro] of course.

When you say... "out of sync" ..... out of sync with the red [metro]..?
You might need to do the same for both?
David.

meters2.pd

I am having some issues here with automating the tempo of second metro (denominator )
The structure is pretty simple
There are 2 metro objects , a red and a blue one
The red one (bottom left corner and left channel ) is triggering a sine , the blue metro is triggering another sine ( bottom right right channel).
Both are using a curve envelope ( cyclone )
The master tempo is located at the top , default is 90 bpm
This goes into a tbf , the float is first send to he right inlet of a division , then the bang is triggering a message of 60000 ms
The result is the time of a beat (one minute divided by BPM) .
It all works fine when disabling-enabling mast toggle but that's not what I want.
Now the issue , the purple and orange boxes all house different denomitor values , used to calculate the new tempo for the second metro ( blue right channel )
When manually triggered these go into a tff , the right outlet of tff goes into a division modue ( green box) and the left output
is trigerring a bang to redo the calculation .
As some of you have guessed , when doing this realtime the second metro is losing sync because of the recalculation .
I tried to automate this ( yellow box, enable spigot ) by sending a bang from the master RED metro into a count-selet module , the ouput is triggering new
denominator values that is send to the tff module (using send receive boxes ) , but again Blue metro is not starting on sync .
Anyone help is appreciated to keep blue metro on sync when receiving a new value .

clock division and clock multiplication for a phaseaccumulator?

division is easy.

[*~ 4.]
[%~ 1.]

but multiplication is more or less impossible, as it would require something to count the current subcycle.

there are a workarounds though. if you want to use a phasor~ and a phasor~ which is 4 times slower, you could

a ) use multiple phasors~ from the beginning on and then select one of them

or, if you need them to be in sync with a "master phasor",

b ) use a phasor which is 8 times slower than the rated rate and derive the base speed phasor from it already using multiplication.

@RT-Chris You would need something like Doc/G09_pitchshift.pd but accuracy would float out the window I think.
As you say [wrap~] can get you the square wave and some leeway on frequency......... https://forum.pdpatchrepo.info/topic/2628/phasor-vs-metro
Just built a test........ maybe.pd
You can get down to half the rate, but below that....... even changing the edge position will not help.
It looks as though there will be problems with increasing the rate above 2.... screenshot below....
...... except multiples of 2..... not sure... lost my maths hat...
The other problem is accuracy if you need a control signal sent from your patch, in which case [metro] is a better choice......... https://forum.pdpatchrepo.info/topic/4098/phasor-vs-metro .... as the block boundary will cause problems.

Of course I am probably wrong and there are solutions.....?
Maybe multiple [expr~] with different but relative edges?
But [wrap~] takes it out of phase so timing from the origin is all messed up anyway.
David.

Hi Junzhe

I often like to think through something like this with a concrete example.

Let's start with 10 seconds of audio: phasor = 0 --> time 0, phasor = 1 --> time 10000 (ms).

Then, at 5000 ms, you change the end time to 7000 ms.

So, now, phasor = 0.5, time = 5000. And you need phasor = 1 now to map onto 7000 ms.

So two things need to happen:

1. The phasor, running at its current speed, would reach its end 5000 ms later -- but you actually need it to reach the end in 2000 ms. So the phasor's speed has to increase by a factor of 5/2 = current_time_to_end / new_time_to_end.
2. The linear mapping currently locates phasor = 1 at time = 10000, but now you need phasor = 1 --> time 7000. So the slope of the linear mapping will have to adjust by a factor of 2/5 = new_time_to_end / current_time_to_end (and the linear function's intercept would have to change too).

The changes in phasor frequency and linear slope should cancel out.

Then, at the start of the next cycle (which can be detected by [samphold~]), you would have to recalculate the slope for the entire start <--> end segment.

I might be overthinking it, but e.g. jameslo admits that in a simpler solution "the pitch is not steady as you adjust the start and end" so I think there aren't many shortcuts to be taken.

BTW there is another way to integrate a rate: rpole~. With an integrator, you don't have to worry about rejiggering slopes -- it just continues on its way, and reaches the end value in its own time. But, you would be responsible for triggering the reset at that point. This version uses control messages for triggering, so it would be quantized to block boundaries. To do it sample-accurately involves feedback and I never worked that out.

integrator~.pd :

And a quick test patch (array "a" is 44100 samples, vertical range -10 to +50):

hjh

PS Hm, now I guess the [route float bang] isn't needed after all.

@nicnut Is there any advantage using [phasor~] instead of [metro] if you are returning to a control rate bang after the audio rate trigger?
Is there any advantage using an audio rate trigger when it will only "bang" at a block end anyway?
Is there any advantage using [threshold~] to trigger on a slope.... when the trigger will be late on the [phasor~] cycle?

If you are looking for accuracy I think you will need to use [vline~] instead of [phasor~] and stay in the audio domain. I am pretty sure that [vline~] will always go to zero and one.... and values will definitely be produced with sub-sample sample accuracy.
You would need to use [metro]....... or some other control rate trigger from your patch...... to bang in the messages to [vline~]
David.
This should be in your doc folder........
C04.control.to.signal.pd