gen~ phasor frequency and phase

    Dec 16 2013 | 10:15 pm
    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?
    Many thanks Brendan

    • Dec 17 2013 | 5:06 am
      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.
    • Dec 17 2013 | 1:46 pm
      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
    • Dec 17 2013 | 1:54 pm
      save this as: monoVoice
      and here's the top level patch:
      thanks for reading
    • Dec 19 2013 | 8:19 am
      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
    • Dec 19 2013 | 10:05 pm
      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.
    • Dec 20 2013 | 5:03 pm
      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.
    • Dec 21 2013 | 11:58 am
      @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 :)
    • Dec 21 2013 | 2:52 pm
      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!
    • Dec 21 2013 | 3:22 pm
      . . . 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
    • Dec 23 2013 | 12:04 pm
      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.
    • Dec 23 2013 | 2:09 pm
      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.
      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!
    • Dec 23 2013 | 2:24 pm
      very small patch:
    • Dec 23 2013 | 3:50 pm
      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.
    • Dec 23 2013 | 5:50 pm
      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.
      Best regards Brendan
    • Dec 23 2013 | 6:16 pm
      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: