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.

Hi Peter
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 :)

Here's the mono version:

I'll post the poly version in a reply

Brendan

save this as:
monoVoice

and here's the top level patch:

thanks for reading

Brendan

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

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.

Many thanks, peoples

Brendan

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:

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

Hi

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

Brendan

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

Have a holiday!

Brendan

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

Smiles!
Brendan