Hello everyone, long time no see.

I've been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share.

[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)

[vphasor2~] is [vphasor~] with an additional signal inlet. This inlet expects another positive-ramping phasor and is used for hard-syncing. When the phasor inlet gets a drop--as happens when a the phase cycle starts over--[vphasor2~] resets its phase to zero. It also does this with subsample accuracy by taking the last and first samples of the phase and estimating when it reset. That's why it needs a positive-ramping phasor as the input. If you try to hard-sync with a sine wave or something, it won't work.

As far as I can tell, everything is working, but let me know if you find a bug. I tried to document the code thoroughly as well.

The sources and helpfiles are included in the zip file. It uses the Makefile template, so just type "make" and it should compile.
vphasor.zip

Thanks for sharing this! Couldn't find a helpfile in the .zip file though..

Thanks guys. @alexandros Woops! Sorry about that. I re-uploaded with the help files.

Thanks!

The legend returns! Pd Con in NYC in November, friend. Come visit.

...and holy shit. This is exactly what I need. Will try it out tomorrow in the studio!

Does this look familiar?

Maestro, il grande ritorno.

So, any chance you could fork [vphasor2~] into a more accurate version of [samphold~]?

@ricky those horizontal patch cords definitely look familiar, lol! ;-p I'm sure a [vsamphold~] wouldn't be difficult. I look into it later today.

I couldn't figure it out how to install this vphaosor~ ... does anybody know where i could get a tutorial or something of that sort?

@Maelstorm Yes, the horizontal patch chords! Thanks, mate. I used vphasor~ today. No distortion, no problems so far.

@slvm93 If you're having trouble compiling, I recommend that you have a look at https://github.com/pure-data/pd-lib-builder

@ricky I haven't tested this extensively, but I think it's working. It uses linear interpolation to estimate the hold value. Could maybe be improved with a 3-point cubic interpolation or something, but I haven't really messed around with that stuff. Like [vphasor2~], it will only work correctly with positive-ramping phasors.

vsamphold~.c

@Maelstorm said:

vsamphold~.c

Thanks!

Seems to be working fine! I'll give it a go tomorrow in the studio.

So, this approach to interpolation might solve some real-time 'live looping' issues? I'm still using poke~ to record audio into a buffer for granulation and I still get a bit of a pop on occasion when I switch on/off [count~] (which) is providing my index for poke~. I tried using Katja's slicerec~ (which gives you some sexy cue-points for your buffer based on attack transient detection / zero crossing) but no dice.

Any thoughts on this, @Maelstorm? I can upload the patches.

Trying to compile this on Mac in Pure Data 50 but I get errors. Do I need to update the makefile?

(Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)

Have a trivial demo patch for this bug?