Phase of the Phasor

    Mar 20 2012 | 4:30 pm
    Hi, I'm trying to make a patch that allows me to change the phase of the phasor object in Gen.
    The bellow doesn't seem to be working.
    My understanding is that if you delay by 2PI you get 90degree shift, 4PI 180 degree etc.

    • Mar 20 2012 | 5:35 pm
      Hi there,
      The phasor in gen~ follows the convention of Max's phasor, in which phase is represented in the 0..1 range (rather than -pi..pi range typical of trigonometric oscillators.) In fact, phasor just delivers a simple ramp from 0 to 1, useful for LFOs, wave-table lookup, etc. As such, it's very easy to 'change' derive another out-of-phase phasor from the first by adding an offset and wrapping in 0..1 again:
      [phasor] -> [+ phaseshift] -> [wrap 0 1]
      Where phaseshift also ranges from 0..1. This is probably cheaper than using a delay. However, if you do want to use the delay technique, what you need to do is delay by some fraction of the phasor period (which is 1./frequency). So that might be something like this:
      Note that I initialized the delay length as 'samplerate', which gives up to 1 second of delay. So this won't work if you drive it with frequencies below 1Hz.
      In general, the offset & wrap technique is going to be cleaner and cheaper, but the delay technique has the advantage of working with any waveform.
      If you want to dig into how phasor works a bit more, take a look at gen~.phasor in the examples folder; this shows what the phasor object is doing internally (more or less).
    • Mar 20 2012 | 7:05 pm
      Thanks so much. That cleared up a lot of things Gen for me.
      I'm trying to use the technique to implement a real time pitch shifter like the one by Sakonda.
      The original is in MSP and uses Tapin~/Tapout~. I thought replacing this with delay in gen might work but I don't seem to get the same results.
      You wouldn't mind looking over much patch for me would you?
    • Mar 21 2012 | 12:02 am
      By default [wave] samples between start and end indices, a bit like the MSP [wave~] object. For what you're doing though, you could just use the [sample] object instead, which by default takes indices from 0..1. (Take a look at the 'buffer-and-data' tab of the gen~ help patch to see the differences between wave, sample, lookup, nearest, and peek.)
      With that it's working for me here. The grainSize wants to be larger to hear the effect (delay times are measured in samples). You could save a bit of memory by using one delay object with 4 inputs (e.g. [delay 44100 4]), which gives several taps from a single delay line. But the rule usually is 1) make it work 2) make it right 3) make it fast (only if you need to)...
    • Mar 21 2012 | 3:21 am
      Ah I see, I'm still getting used to the Gen vocabulary but this seems to get it working.
      I implemented the multidelay and a few other features but I've come across another problem.
      On a lot of setting I seem to get the dry sound passing through along with the effected sound when I should only be getting signal from the delay line.
      Does delay in gen allow the dry signal through as standard?
    • Mar 22 2012 | 5:24 pm
      No, the delay operator only sends the wet (delayed) signal.
      As much as it would be nice, unfortunately [delay samplerate*0.5] doesn't work, so you're probably getting the default size of 512 samples for the delay line. That might explain why it sounds dry?
    • Mar 25 2012 | 1:37 pm
      hello, you should have a look here :
    • Mar 25 2012 | 1:52 pm
      Ah I see, my understanding was constants like samplerate and pi were accessible by word commands. I can use the samplerate command outside of the delay object though right?
      Thanks for the link @fp, I see this task has already been tackled in a way.
      Cheers guys
    • Mar 25 2012 | 9:37 pm
      Constants like pi, twopi etc. and globals like samplerate and param names are available to use as object arguments, but expressions like pi*0.5 are not valid as object arguments.
      This may be somewhat extended in a future update however... :-)