Phase reset in gen~ vs msp


    May 26 2019 | 2:06 pm
    I'm getting much harsher clicks and inconsistency in sound when resetting the phase in gen~ vs msp. I'd like to get the gen~ version sounding the same as the msp version. Any ideas on how I might be able to do this?

    • May 26 2019 | 4:23 pm
      It sounds like there is some sort of smoothing magic built in to the msp cycle~ for the phase reset.
    • May 26 2019 | 8:20 pm
      Since gen~ works on individual samples and any MSP object works on bundles of samples (signal vector size), you're likely to see a difference. You'll need to work out some method of doing the smoothing (perhaps the slide operator would be a help, or some patching to provide you with a running average.
    • May 26 2019 | 9:36 pm
      Cool, thanks for the reply. I'll see if I can figure that one out.
    • May 27 2019 | 4:16 pm
      I don't think cycle~ has smoothing for the phase reset. In the case of the patcher above, if you bypass the curve~ and hear the raw sine, I think you can hear the same kinds of clicks from both cycle~ and gen~.
      Your patcher's difference is due to message/signal scheduling to curve~/cycle~ and click~. What I see is that the curve~ triggers together with the cycle~, but the click~ (and thus the gen~ processing) triggers later (see image below). Bascially, don't trust the timing of click~. I've pasted patchers below that show a couple of alternate methods to messge-trigger gen~, which are click-free. One uses a history node to trigger (it looks weird but works perfectly), the other detects the rising edge of the curve~ (will work so long as your envelope is a standard ADSR kind of shape).
      Also of course you should have scheduler in audio interrupt (audio options menu) to ensure messages are sequenced with audio together.
      Also of course, you could avoid using messages at all and do the triggering & enveloping all in gen~...
      Using history node trick:
      Using rising edge detection:
    • May 27 2019 | 5:26 pm
      Thank you, Graham. That solves the problem perfectly. Much appreciated.
    • Mar 17 2020 | 8:24 pm
      Thank you for the rising edge detection code... I was going crazy trying to find a way to reset the phasor inside a gen patcher through another one outside of it (without converting any signal to data and so using gen not msp). Really, going mad
    • Mar 17 2020 | 10:01 pm
      On the topic of phasors edge detection, another couple of patterns I've beenusing a lot recently:
      - detect the phase wrap of a phasor, regardless of direction: phasor -> [delta @init 1] -> [abs] -> [> 0.5]
      - recover ideal slope ( == freq/samplerate) of phasor, even during wrap transition: phasor -> [delta @init 1] -> [wrap -0.5 0.5] -> accurate slope - turn this into a continuous and reset-able counter at the rate of the phasor: accurate slope -> [+= @resetmode pre] (the 2nd inlet can be used to reset the counter) - turn this into a locked out of phase phasor by [+ offset] -> [wrap 0 1]. This 2nd phasor will maintain a constant phase offset from the original, regardless how much the original is modulated.
      Graham