@DesignDefault Welcome to the Forum...!

Sorry, this will be a lot for a newbie.

You will see in the video @ricky has linked to that the [phasor~] object controls the speed at which the array is being read.
So you will need to increase the number that it receives at its left inlet in order to increase the speed.
It is an audio rate inlet, so you will need [sig~] to convert a control rate 1 to a signal rate 1.
1 will play at normal speed, 2 at double that speed etc.

Unfortunately you will need to "catch" a moment in the [phasor~] loop using [edge~] and then increment that value to [sig~] by whatever increase you want each time that [edge~] outputs a bang.
Catching the exact moment that it loops can be awkward and you might well need to add or subtract a value from the output of [phasor~] before sending it into [edge~]

A more reliable method would be to use a [metro] to increase the [sig~] with the metro rate set by the value from [timer].

Also, before playback (it only needs to be done once for the array after it has been filled) extra data points should be added.
That will stop clicks as [phasor~] wraps back to the beginning of the array.
https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
That will add 3 data points to the array, allowing [tabread4~] to correctly interpolate the samples at wrap around.
For that to work properly you should then add 3.... [+ 3] to the total number of samples after the [* 44.1]

Also, if you are running Pd at 48000Hz the [* 44.1] should be changed to [* 48] for the initial playback speed to be correct.
David.

@porres said:

to never miss a period, but I also think this is a job for a C code.

To atone for my earlier SC jibe, here's a delay-based approach. (Also, indeed you're right -- I hadn't read the thread carefully enough. Dust / Dust2 don't implement exactly "one pulse per regular time interval, randomly placed within each interval.")

velvet-noise-2.pd

Uses else's del~ because delread~ requires a message-based delay time, which can't update fast enough, and delread4~ interpolates, which smears the impulses. With del~, I could at least round the delay time to an integer number of samples, and AFAICS it then doesn't interpolate.

It looks to me in the graphs like there is exactly one nonzero sample per phasor~ cycle.

hjh

PS FWIW -- one nice convenience in SC is that non-interpolating DelayN doesn't require the delay time to be rounded

(
a = { |density = 2500|
    // var pulse = Impulse.ar(density);
    // for similarity to Pd graphs, I'll phasor it
    // but the Impulse is sufficient for the subsequent logic
    var phasor = LFSaw.ar(density);
    var pulse = HPZ1.ar(phasor) < 0;
    var delayTime = TRand.ar(0, density.reciprocal - SampleDur.ir, pulse);
    var rand = TRand.ar(-1, 1, pulse).sign;
    [DelayN.ar(rand * pulse, 0.2, delayTime), phasor]
}.plot;
)

@earlyjp There might well be a better way than the two options that I can think of straight away.

You could play the audio file from disk, and send a bang into [delay] objects as you start playback, with the delays set to trigger the messages at the correct time.
I am not sure how long a [delay] you can create though because of the precision limit of a number size that can be saved in Pd. You might need to use [timer] banged by a [metro]

Or as you say you could load the file into RAM using [soundfiler] and play the track in the array using [phasor~] and trigger the messages as the output of [phasor~] reaches certain values.
Using [phasor~] the sample will loop though.
To play just once you could use [line~] or [vline~]
You would need to catch the values from [phasor~] [line~] or [vline~] using [snapshot~].
[<=] followed by [once] would be a good idea for catching, as catching the exact value would likely be unreliable...... once.pd
The same will be true if you use [timer] as the [metro] will not make [timer] output every value.

Again, number precision for catching the value could be a problem with long audio files.

Help for the second method....... https://forum.pdpatchrepo.info/topic/9151/for-phasor-and-vline-based-samplers-how-can-we-be-sure-all-samples-are-being-played

The [soundfiler] method will use much more cpu if that is a problem.
If there is a playback object that outputs it's index then use that, but I have not seen one.
David.

@manuels That's clever, thanks! I especially like how you get the slope of the input phasor (compensating for that downward jump every cycle) and how you construct the output phasor. But I think there are two issues with it. Firstly, a sync will reset the phase of the output phasor at an arbitrary point unless the output phasor frequency is an exact multiple of the input frequency. Secondly, without sync, I think the output phasor may drift WRT the input phasor due to floating point roundoff error. Agree?

Backing out to look at the big picture again, i.e. Brendan's question, this means that it couldn't be used to make either a "hardsync" synthesizer (disclaimer: I don't really know what that is) or a "phasor~-synchronized system", assuming that both require a precise phase relationship between the input and output phasors and that the output phasor doesn't contain discontinuities. What do you think?

@seb-harmonik.ar said:

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Must be.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.

SC UGens are free to use doubles internally, but the interconnection buffers are single precision, so we do run into trouble at that 24 bit mantissa limit.

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit...

I think it's a bit more than that. When the phase increment is 1 buffer frame per output sample, then there is no inaccuracy at all, because integer values are never repeating fractions, and up to 2^24, are not subject to truncation (2^24 - 1 is ok but 2^24 + 1 is not). It avoids the problem of scaling inaccuracy by not scaling at all -- which may be what you meant, just being clear about it. rpole's similar results are because my example is integrating a stream of 1's, so everything is integer valued.

It struck me interesting how the correct observation "buffer playback by scaling phasor~ runs into trouble quickly" slips into a generalized caution. Agreed that the phasor~ way isn't sufficient for many use cases; perhaps a new object would be useful, or, the accumulator technique would be useful as a more prominent part of pd culture.

hjh

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.. https://github.com/supercollider/supercollider/blob/137cb4cd56f5bdf4484c9ad6761d4724dc8d7818/server/plugins/TriggerUGens.cpp#L134

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit whereas when using phasor~ it is output as 32-bit and also scaled from range 0-1 as a 32-bit by multiplying by buffer size

If there were a Phasor equivalent in pd it might be comparable..
(and that also seems to be the case if [rpole~] gives similar results)
[vline~] should work as well

Hi all, beginner here.
I'm trying to find a way to simultaneously modulate my METRO time and the ramp time of my LINE. I tried to crudely illustrate that concept in the red line drawing on my patch.

What I have here is

1. METRO sends regular pulses to RANDOM
2. with each pulse RANDOM chooses a random value
3. values ramp from one to the next via LINE
4. LINE passes values to NUMBER
5. NUMBER passes values to PHASOR~ as frequency values

I want to be able to use one control that overrides the METRO time with a value that simultaneously becomes my LINE's ramp time. So when METRO is 1000ms, LINE ramp time is also 1000ms; when METRO is 750ms, LINE ramp time is also 750ms, etc.

Any insights on how to patch this up? Thank you!

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

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.

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 .