Hey guys,
Thank you very much for checking this out. I'm glad you guys like.
Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. And I did [+~ 2] instead of [+~ 1] because thought I read somewhere that [phasor~] actually goes all the way up to 1 instead of just before it. I don't know if that's actually true or not, though, but I figured adding 2 is easier than looking at the source. ;-)
Thanks again, .mmb
Roman Haefeli wrote:
On Sun, 2010-04-18 at 11:25 +0200, Frank Barknecht wrote:
On Fri, Apr 16, 2010 at 08:19:09PM +0200, Frank Barknecht wrote:
Mike's trick then is to take a snapshot~ of the original phasor at the moment of the desired phase resetting. If you substract that value from the original phasor, you get a phasor~ shifted up or down just by the value it had when the phase was last reset.
Now you can add in the desired phase value again to get a wrap-phasor that is out of sync to the original phasor in exactly the desired fashion.
Actually I meant two write "take a [samphold~] of the original phasor". Taking a snapshot~ or rather, a vsnapshot~ is something I have also tried, but it gives the wrong results. See attached example for a comparison of [vsnapshot~]->[vline~] with Mike's [samphold~] solution (which I simplified a bit). Lesson to learn: [vsnapshot~]->[vline~] won't do what you may expect it to do.
Before this thread was started, I also was thinking of a [vsnapshot~] based solution. But I didn't even start to try to implement it, because it includes a loop (message -> audio -> message) that will certainly introduce a latency, which breaks the goal of accuracy completely.
I find Mike's loopless [samphold~] based solution very elegant.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list