Hallo, padawan12 hat gesagt: // padawan12 wrote:
I guess just because they drift off. Or at least you cant be sure of keeping them together.
Sometimes you want a whole bunch of things to all happen "synchronously", to all happen in the same phase every time. An example is the paf~ algorithm, and here's little drum machine example attached. So you usually have just one phasor that is your master timebase and derive everything from that.
[metro] with [vline~] won't drift off, as I wrote in the previous mail, it is equivalent to [phasor~] and can almost be used as a drop-in replacement. ([metro] has an artificial lower period boundary of 1ms, but you can use a [delay] based metro-clone, if that is a problem.)
The disadvantage of [metro~]/[vline~] is that you cannot change the frequency in a smooth way, because, as you write, [metro] generates discrete events. The advantage of [metro]/[vline~] is, that it is possible to reset the phase without getting errors from the 64-samples quantization that [phasor~]'s right inlet has: The phase of a [phasor~] can only be reset every 64 samples, that is with usual sample rates at a quantization of about 1.5 msec. This definitely can be a problem if you want a tight synching of sequences.
I made a variation of your drum machine to illustrate this effect. One drumset here is driven by a [vhasor~] abstraction which almost is a [phasor~] clone, built with metro and vline~. If you let both patterns run together and switch on the phase-reset-metro you will get flanging effects which are the fault of the inaccuracy of the phase-inlet of the [phasor~] object.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__