brendan mccloskey

I have encountered a minor technical hitch that is undermining an otherwise perfect little gen~ granulator. Using the voice/instance numbers from [thispoly~] I assign each phasor inside gen~ a unique phase, for smoothly overlapped grains, and all granular parameters are quantized to this central phasor. It works very, very well indeed except for the grain "size" (frequency) parameter. When this is varied, the initialised phase-offset relationships disappear. For example, four grains would initialise with unique phases of 0.25, 0.5, 0.75 and 1. Varying any other parameter (pitch, range, scrub etc) does not appear to alter these phases (using my ears not my slide-rule). Varying the size does though. How should I ensure that these equal phase offsets are retained during frequency (size) changes to the phasor. Oh, and what's the best way to post the gen~ code? As a named gen~ object, plus patch, or copy-paste the code?

Hi
I have encountered a minor technical hitch that is undermining an otherwise perfect little gen~ granulator. Using the voice/instance numbers from [thispoly~] I assign each phasor inside gen~ a unique phase, for smoothly overlapped grains, and all granular parameters are quantized to this central phasor. It works very, very well indeed except for the grain "size" (frequency) parameter. When this is varied, the initialised phase-offset relationships disappear. For example, four grains would initialise with unique phases of 0.25, 0.5, 0.75 and 1. Varying any other parameter (pitch, range, scrub etc) does not appear to alter these phases (using my ears not my slide-rule). Varying the size does though. How should I ensure that these equal phase offsets are retained during frequency (size) changes to the phasor. Oh, and what's the best way to post the gen~ code? As a named gen~ object, plus patch, or copy-paste the code?

gen-phasor-frequency-and-phase

Copy compressed should work fine (in the containing patch.

Is the frequency information transmitted at signal or control rate?

I think you might be better off transmitting a central phasor signal to the poly~ voices if you really want to maintain the phase relationships.

Copy compressed should work fine (in the containing patch.  

Is the frequency information transmitted at signal or control rate? 

I think you might be better off transmitting a central phasor signal to the poly~ voices if you really want to maintain the phase relationships.


yes, placing the phasor outside poly solves this problem, thanks.

It does, however, cause it's own little issues: pitch modulation occurs during changes to the size/frequency value. Your "delta/sah" trick from a few months ago solves the issue, when the phasor is outside gen~, in a mono version. When I try to poly-phonise it (with phasor at the top level), the sah trick doesn't work. Apologies for banging on about this over the past few months :)

Hi Peter
yes, placing the phasor outside poly solves this problem, thanks.

My question has fallen off the bottom of page 1, so I'm restating the issue, to try and solve it.

Altering the frequency of an oscillator interrupts its phase; during this interruption, pitch modulation occurs and the only solution to the issue, of immutable phase-offsets for multiple phasors, would be to reset the unique phase offsets for each oscillator 

 the frequency is changed, and for all of them. This is clearly unworkable. So, my alternatives are to use a single phasor "outside" the poly~ collection as Peter suggests; using sample and hold, the unwanted pitch modulation is solved, but only if poly~ is using 

. Additional voices are not aligned to this one sample and hold, so frequency changes occur mid-ramp, and the pitch modulation reappears in the offset phasors. This much is clear.

The only alternative left, as I see it, is to use multiple sample-and-hold's, inside each gen~ iteration, driven by each offset phasor ramp.

If there are alternatives to the problem - how to mask pitch modulation during master frequency changes to multiple phasors AND retaining unique phase offsets - then please do feel free to chime in.

Altering the frequency of an oscillator interrupts its phase; during this interruption, pitch modulation occurs and the only solution to the issue, of immutable phase-offsets for multiple phasors, would be to reset the unique phase offsets for each oscillator every time the frequency is changed, and for all of them. This is clearly unworkable. So, my alternatives are to use a single phasor "outside" the poly~ collection as Peter suggests; using sample and hold, the unwanted pitch modulation is solved, but only if poly~ is using one voice. Additional voices are not aligned to this one sample and hold, so frequency changes occur mid-ramp, and the pitch modulation reappears in the offset phasors. This much is clear.

Instead of using phase offsets and phase wrapping you could use something like a signal triggered line~ object. You can use zigzag~ or the external shot~ for that. I've also seen a gen~ patch for this purpose on the forums. You can use your phasor~ as the master clock and trigger a ramp when your phasor is at 0 and when it's at 0.5. This way you can make sure that the speed of your ramp doesn't change.

Here's an example. It doesn't seem to work at high speeds though. But it makes the idea clearer. 

Instead of using phase offsets and phase wrapping you could use something like a signal triggered line~ object. You can use zigzag~ or the external shot~ for that. I've also seen a gen~ patch for this purpose on the forums. You can use your phasor~ as the master clock and trigger a ramp when your phasor is at 0 and when it's at 0.5. This way you can make sure that the speed of your ramp doesn't change. 

Here's an example. It doesn't seem to work at high speeds though. But it makes the idea clearer. 


Hi Brendan, finals week here, hence the slow reply.

As an alternative, you could create local one-shot ramps. When the master phasor goes above the threshold (phase offset), they get triggered and use sah to grab the current phase increment which should be something like this:

// You may want to make sure this can't happen until the previous oneshot has completed

dx = sgn_dx * min(dx,1-dx); // the second is only bigger when it jumps

This is back of envelope, but I think it'll do. The local phase relationships won't change until the next triggering, but it should be globally accurate and not as subject to modulation woes.

As an alternative, you could create local one-shot ramps.  When the master phasor goes above the threshold (phase offset), they get triggered and use sah to grab the current phase increment which should be something like this:

// Grab phase inc
// You may want to make sure this can't happen until the previous oneshot has completed
dx = delta(from_phasor);
sgn_dx = sign(dx);
dx = abs(dx);
dx = sgn_dx * min(dx,1-dx); // the second is only bigger when it jumps

This is back of envelope, but I think it'll do.  The local phase relationships won't change until the next triggering, but it should be globally accurate and not as subject to modulation woes.


@Dave: I think I know the patch you're talking about; did it use the [accum] function in Gen? I'm hoping to avoid that method, to try to mimimize CPU/memory demands. As for your main suggestion, I tinkered with your patch - using [zigzag~] in place of [shot~], which I don't have - and I was unable to even get it to do anything at all, despite hacking zigzag's helpfile (it's not an object I'm familiar with). I think I grasp the practicalities, if not the concept, of your suggestion though, thanks.

@Peter: super-busy here too so I empathise completely. I'm similarly dazzled by this concept; I'm okay up until "use sah to grab the current phase increment". And I'm not clear about the variables in your example function either I'm afraid.

Many thanks again for chipping in gents*.

*At a wedding recently I was told that having just a son and daughter (as I do) used to be called "a Gentleman's family"; never heard that one before :)

Ok; I seem to be going in circles with this one. I recall posting a very similar question some time ago, without resolution. It may stem from my misunderstanding of the way sah and ramps operate. And it is sah that's causing the pitch modulation.

Let's forget about the phase-offsets for now. When I change the freq/size param to a phasor (driving [play~] in this method) pitch is not affected but the ramp is interrupted, causing clicks. So I add a sah, to only update frequency at the end of the ramp. Clicks disappear. Pitch modulation appears.

So the question in its simplest terms is: do I have to choose between either no pitch-mod, with clicks, or click-free with pitch mod? And why can I not have both (n00bosity nothwithstanding)? And strictly speaking this is no longer a gen-specific question.

Ok; I seem to be going in circles with this one. I recall posting a very similar question some time ago, without resolution. It may stem from my misunderstanding of the way sah and ramps operate. And it is sah that's causing the pitch modulation. 

. . . it's because the free-running master phasor is not being sah'ed ! ! Doh!

Still not perfected, but I fear I am going to continue chasing my own tail on this

Here's a patch that triggers one-shot ramps.

I made a phasor in gen~ that changes its frequency at zero phase only. And in sync with this master phasor I trigger one-shot ramps. The frequency of this ramp can't be changed mid-ramp. This way you don't have any pitch modulation anymore. There are probably still some disadvantages to this technique though.

You might also think of delaying your master phasor to get a phasor out of phase. 

Here's a patch that triggers one-shot ramps. 

I made a phasor in gen~ that changes its frequency at zero phase only. And in sync with this master phasor I trigger one-shot ramps. The frequency of this ramp can't be changed mid-ramp. This way you don't have any pitch modulation anymore. There are probably still some disadvantages to this technique though. 

You might also think of delaying your master phasor to get a phasor out of phase. 


thanks again for contributing; sadly, the phase offsets are not immutable - they drift/change when size is varied. Strangely, it is more common when size is reducing; when size increases, the 50% shift appears to be maintained. I've tried the delay solution as well and, as you guess, it presents its own problems too.

I'm rapidly coming to the conclusion that it is impossible to guarantee fixed and immutable phase offsets, when freq is variable. I've shown this to be the case: if I avoid [poly~] I can get immutable phase offsets (0. and 0.5) but as soon as I polyphonise, it all goes t' shite! They WILL initialise with the required offsets, but then freq changes infect everything. Bumholes!

Hi Dave
thanks again for contributing; sadly, the phase offsets are not immutable - they drift/change when size is varied. Strangely, it is more common when size is reducing; when size increases, the 50% shift appears to be maintained. I've tried the delay solution as well and, as you guess, it presents its own problems too.

This sounds nice to me. Even though your 50% out of phase phasor is still interrupted mid-ramp. It goes to the new frequency at a phase of 0.5. That is fixable with my method. But like you noticed, it introduces some drift.

So I would just stick to your patch. But I'm amazed this doesn't work in poly~ actually.

This sounds nice to me. Even though your 50% out of phase phasor is still interrupted mid-ramp. It goes to the new frequency at a phase of 0.5. That is fixable with my method. But like you noticed, it introduces some drift. 

So I would just stick to your patch. But I'm amazed this doesn't work in poly~ actually.


Correct, the offset ramp is interrupted halfway through, but it was just for demonstration; and thanks again for your solution.

What about an algorithm that does the following?

When the frequency value stops changing, reset all phases to their initial offset. This would just mean detecting when the freq value signal stops moving, and then forcing the central phasor to a phase of 1., and all others to their offsets?

I'll try that; if it fails, i'll look for a solution using a randomised allpass~ delay offset. But I think the fundamental problem will persist: changing frequency will inevitably disturb phase.

And I may have to qualify what I said previously about it somehow being poly~'s fault; the patch below clearly demonstrates that the phase 

And I may have to qualify what I said previously about it somehow being poly~'s fault; the patch below clearly demonstrates that the phase offsets are not disturbed by changing the frequency:

https://cycling74.com/forums/sahhistory-disturbs-phase-in-polygen/#new-topic-0

gen~ phasor frequency and phase