gen~ woes (history/sah)


    Feb 13 2013 | 3:05 pm
    Hi I am using a gen algorithm to generate a mutable ramp, with a built in phase offset of 50% of ramp size. To avoid spikes/clicks when I vary the ramp duration I have added a history/sah pair but this doesn't solve my spikes/clicks issue. The unshifted ramp is clean, the shifted ramp dirty. can someone assist please?
    Please find a simple patch below:

    • Feb 13 2013 | 6:22 pm
      This seems to take care of it. You might want to up the minimum frequency requirement in the clamp so you don't get stuck on a really long, low frequency for a long time...
      Perversely, the solution was to sah the main oscillator, not the slave.
    • Feb 13 2013 | 6:49 pm
      It does indeed Peter; again, many thanks. As I am restricting the duration to c. 1000/10-200 Hz, and the interonset to >=0, could I just set the clamp to that range?
      I had tried various values and routing of the sah/history and trigger-source.I did notice, in my original above, that changing the sah trigger threshold had some strange results. Therefore, can I ask why history ---> == 0 ---> sah0.5 works "better"?
      I can now surge ahead with what I promise will be a very VERY flexible and clean granular stretch/playback/synthesis tool.
      Brendan
    • Feb 13 2013 | 7:05 pm
      The problem with your original is that you had a threshold of 0, which a phasor will never go below. (I think it has to go below the threshold, not just to it)
      I like to use 0.5 when I'm triggering SAH with binary values. I avoid phasor -> sah 0.001 because I like to time it more precisely to the start of the cycle. My preferred means is delta -> abs -> > 0.5, but it seemed like overkill since we can guarantee that the frequency will be positive.
    • Feb 17 2013 | 2:51 pm
      update:
      Your sah method works well, but a problem persists: thanks to your input I have successfully set up a sah inside gen to pass the size value out at the end of an entire single ramp, but sah-ing this signal for the shifted version continues to prove a headache. No matter which sah method I use, or whence I derive the control signal, the shifted window continues to exhibit spikes. Again, the simple patch below describes the the 3 steps I've taken to get from no spikes, to independent pitch/size, to spikes returning:
      Brendan
    • Feb 17 2013 | 3:08 pm
      ps
      it should be pointed out that the reason I need to use sah is to avoid not only spikes, but also to "hide" unwanted pitch variation during changes to ramp size; I'm going for completely independent grain size and pitch......
    • Feb 19 2013 | 12:43 pm
      I was a bit confused what the goal was; having independent control of the period between grains doesn't seem to match up with having grains 50% out of phase; see the waveforms here:
    • Feb 19 2013 | 12:47 pm
      ... sorry, posted too soon, didn't finish what I was trying to say...
      If the goal is that grains always smoothly overlap at 50% phase, then the period between grains will always be grainsize/2. Which can make the patch design a lot simpler I think.
      But maybe I've misunderstood the goal. You said you wanted a granulator with independent pitch & grain size; this can be done without needing the 50% overlap mechanics....
      There are a few granulation/shifting/stretching patches in the gen examples folder, which show a few different techniques. There can be more.
    • Feb 19 2013 | 3:27 pm
      Hi Graham thanks for taking the time to respond to this question, and you're quite right, some clarification is needed:
      [1] 50%phase offset should be immutable, irrespective of mute duration, therefore; [2] delay offset is a function of size; [3] gen sampling/holding of size signal is required so it can be passed back out to the first multiplier (ramp*size[via sah]=no pitch variation)
      I have also restated and simplified this question, here: https://cycling74.com/forums/gen-issue-clarified-and-restated
    • Feb 19 2013 | 3:37 pm
      ps the single issue, as I see it, lies here. I'm just waiting for someone to say "if you don't know how to use gen~ then don't use it!!!!"
      My single question is, how can I correctly sample and hold the size value for the shifted window, so there are no discontinuity clicks/spikes in the offset window. No such discontinuities appear in the non-shifted window.
      Best regards Brendan
    • Feb 19 2013 | 7:49 pm
    • Feb 21 2013 | 7:22 am
      Uh, I'm going to reply here because the other thread seems to have a different tangent...
      I'm on the cellphone so I can't post a patcher, but the simplest sample/hold is a [?] and [history] pair. Hook the out of the history to the last input of the [?]. Hook the out of the [?] to the in of the [history]. Hook whatever source to sample to the middle inlet of [?]. Hook your trigger condition up to the first input of [?].
      E.g. the trigger condition could be when the ramp phase is >= the ramp length. If the trigger for the sample & hold is further down the signal flow, you'll need to add another history to handle this feedback.
      There should also be a way to do this without needing to use a delay, but it might mean re-thinking the ramps in terms of sample counters rather than phasors.
      Also take a look again at some of the slicer / pitch-shifter / chopper etc. examples in the gen examples folder; I know that some of them also do smooth parameter updates.
    • Feb 21 2013 | 6:40 pm
      Hi Graham yes, I've been browsing the gen examples you cite and the pitchshifter has a nice phase-modulation algorithm I've been trying emulate.
      A contributory factor in my struggles with this is that I've tried to get very smooth grains (using phase-mod, size/freq mod, fixed phase-shift) in a strictly monophonic grain player, with the intention of polyphon-izing it later. What I'm doing now is fixing such parameters and then randomizing them in a polyphonic version.
      Thanks again for your help
      Brendan
    • Mar 26 2013 | 1:42 am
      Hi.It's a very old problem isn't it. This could help:
      And I welcome comment for a future toolbox contribution.