roger.carruthers

With a 'free running' phasor~ sah~ and wait~ behave in pretty much the same way.

With a phasor~ @lock 1, wait~'s output is smoothed/interpolated. Is this expected behaviour, and if so can someone explain?

What's happening in the patch below?
With a 'free running' phasor~ sah~ and wait~ behave in pretty much the same way.
With a phasor~ @lock 1, wait~'s output is smoothed/interpolated. Is this expected behaviour, and if so can someone explain?
Cheers
Roger


wait-transport-lock-1

I know it's only been a day, but I have replaced sah~ with wait~ in a load of patches and was beginning to wonder if I'd done Stupid Thing...

Why use wait~ instead of sah~ ? Principally because I'd been reading Puckette's excellent book and wait~ seemed to be a more direct replacement for the PD samp/hold object (whatever it's called), making it easier to reproduce some of the patches.

But then intuitively it seemed a bit more like what a sample & hold object /should/ do, or am I missing something?

Curious anyway - why doesn't it work with a transport-locked phasor~ ?

It's obviously related to signal vector size as the behaviours converge at lower BPMs/smaller signal vectors,e.g. at 256 it changes between 47 and 48 BPM...

No-one?
I know it's only been a day, but I have replaced sah~ with wait~ in a load of patches and was beginning to wonder if I'd done Stupid Thing...
 Why use wait~ instead of sah~ ? Principally because I'd been reading Puckette's excellent book and wait~ seemed to be a more direct replacement for the PD samp/hold object (whatever it's called), making it easier to reproduce some of the patches.
But then intuitively it seemed a bit more like what a sample & hold object /should/ do, or am I missing something?
Curious anyway - why doesn't it work with a transport-locked phasor~ ?
It's obviously related to signal vector size as the behaviours converge at lower BPMs/smaller signal vectors,e.g. at 256 it changes between 47 and 48 BPM...
Cheers
Roger


It has been awhile since I worked on wait~, but the way it works internally is that it looks for the edge of the phasor~ signal by comparing the difference between successive samples. With @lock 1 I think that there is more discontinuity in the ramp signal than I was accounting for in the object perform loop. I've been considering redoing the object anyways (with 64-bit MSP Max6 code). Do you have Max 6? If so, try the attached patch which uses gen~ to do the job. 

It has been awhile since I worked on wait~, but the way it works internally is that it looks for the edge of the phasor~ signal by comparing the difference between successive samples. With @lock 1 I think that there is more discontinuity in the ramp signal than I was accounting for in the object perform loop.  I've been considering redoing the object anyways (with 64-bit MSP Max6 code).  Do you have Max 6? If so, try the attached patch which uses gen~ to do the job.  


Thanks, but I can see now this is not just an issue with wait~ (see patch below). There's some weirdness going on with phasor~ @lock 1.

I've checked your gen~ version and it works nicely,thanks, but I have a project I have to complete in Max 5, and I realise now that this issue with transport is causing problems elsewhere.

This is surely not the expected behaviour...?

Thanks, but I can see now this is not just an issue with wait~ (see patch below). There's some weirdness going on with phasor~ @lock 1.
 I've checked your gen~ version and it works nicely,thanks, but I have a project I have to complete in Max 5, and I realise now that this issue with transport is causing problems elsewhere.
This is surely not the expected behaviour...?
Cheers
Roger


Wait~ & transport @lock 1