i want a phasor~ to send a bang when the signal reaches 1. any ideas?
[phasor] [bang~] | / [snapshot~] | [> 0.99] | [sel 1]
?
Jamie
On Fri, 2006-12-01 at 22:35 +0900, hard off wrote:
i want a phasor~ to send a bang when the signal reaches 1. any ideas?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi, Are you aware, that with interpolation the signal might not reach 1 but reset the phasor at some point below 1? so it depends how accurate the bang should be. My idea is to use the derivative of the function, which is negative at the point where the phasor~ resets. you will need some objects from zexy. m.
hard off wrote:
i want a phasor~ to send a bang when the signal reaches 1. any ideas?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 236 266 450 338 10; #X obj 113 92 z~ -1; #X obj 96 124 -~; #X obj 96 152 <~ 0; #X obj 96 200 snapshot~; #X obj 95 53 phasor~ 0.3; #X obj 137 176 bang~; #X obj 96 222 > 0; #X obj 96 245 sel 1; #X obj 96 271 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 96 175 avg~; #X connect 0 0 1 1; #X connect 1 0 2 0; #X connect 2 0 9 0; #X connect 3 0 6 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 5 0 3 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 9 0 3 0;
Hallo, Steffen hat gesagt: // Steffen wrote:
On 01/12/2006, at 14.35, hard off wrote:
i want a phasor~ to send a bang when the signal reaches 1.
I the risk of showing off serious lack of knowledge: When is this
approach different from using a metro object with the same
"frequency" as the phasor~?
A [metro] driving a [vline~] can generate the same signal as a [phasor~], so there is no difference. However with the metro it will be much easier to know when the fake phasor reaches 1 or 0.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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.
The difference is that with a metro you get messages as discrete events, but with the phasor you get a continuous time marker - try changing the tempo in the drum machine example to something very low ;)
On Fri, 1 Dec 2006 21:22:21 +0100 Steffen stffn@dibidut.dk wrote:
On 01/12/2006, at 14.35, hard off wrote:
i want a phasor~ to send a bang when the signal reaches 1.
I the risk of showing off serious lack of knowledge: When is this
approach different from using a metro object with the same
"frequency" as the phasor~?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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__
well i ended up doing a metro and vline~ job. this patch is still unfinished, but it's working enough that i could take a rest from patching and have a mess round with it today. i posted the workign draft on the forum:
On Sat, 2 Dec 2006 11:57:44 +0100 Frank Barknecht fbar@footils.org wrote:
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.)
Nice Frank, this is a great way of getting an LFO. Is it just me though or is [expr ] really slow? I try to avoid it because almost every patch that uses [expr] on my machine runs about 50% slower than the equivilent arithmetic using atomic ops.
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.
OK, I tried that. I can hear the flanging and it's pretty severe. Thanks for pointing it out, the 64 sample grain annoying. I think for many compositional uses you only need to set relative phases once at the start, but I can see it being a royal pain in the ass if you need to re-sync parts.
Cheers, Andy
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Is it just me though or is [expr ] really slow? I try to avoid it because almost every patch that uses [expr] on my machine runs about 50% slower than the equivilent arithmetic using atomic ops.
Attached is a simple benchmark patch, which benchmarks taking the inverse in e/b-calc. Here builtin and expr are almost the same speed, builtin is only slightly faster.
However as soon as you collect longer chains of calculations into one expr-object it beats the crap out of atomic ops, as the e/b-complex benchmark shows. If it doesn't pulp the atomic ops in your Pd installation, then there's something very wrong. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Cool! We've discovered something "very wrong".
Here I get
number bcalc ecalc bcplx ecplx
4 70 80 110 290 8 140 160 210 560 16 260 330 430 1130 32 560 660 1070 2300 64 1220 1490 3250 4720
with 0.39r4 on $ cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 533.507 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1052.67
On Sat, 2 Dec 2006 17:07:28 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Is it just me though or is [expr ] really slow? I try to avoid it because almost every patch that uses [expr] on my machine runs about 50% slower than the equivilent arithmetic using atomic ops.
Attached is a simple benchmark patch, which benchmarks taking the inverse in e/b-calc. Here builtin and expr are almost the same speed, builtin is only slightly faster.
However as soon as you collect longer chains of calculations into one expr-object it beats the crap out of atomic ops, as the e/b-complex benchmark shows. If it doesn't pulp the atomic ops in your Pd installation, then there's something very wrong. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Cool! We've discovered something "very wrong".
Maybe not, read on.
Here I get
number bcalc ecalc bcplx ecplx
4 70 80 110 290 8 140 160 210 560 16 260 330 430 1130 32 560 660 1070 2300 64 1220 1490 3250 4720
Hm, you're right, with such small numbers I actually also get better results for the builtins. I was only testing bigger numbers at first.
With a growing number of test objects I get a huge lead for [expr]. Here are some of my statistics (on a much faster machine):
num bcplx ecplx
128 720 1170 256 2780 2320 512 10430 5800
Now I'm wondering, if something became "very wrong" with [expr] ...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
The solution Marius offered is probably the most reliable. I've used Jamies [snapshot~] based solution in many cases it works fine, but sometimes misses a beat. It's because the blocksize (nominally 64) on which [snapshot~] operates may not contain the zero you're looking for.
The thing you want is [delta~], but you can make your own arrangement with a [z~] and a [-~]. Basically look for any large dx/dt, not just negative, remember that a phasor can also be negative in slope, ie [phasor~ -100]. See also that as the frequency increases toward a high value eventually the solution will fail (each rising slope will be sufficiently fast to trigger the delta comparator.
Theres probably a more elgant solution, I heard Martin Brinkman is a good chap to ask as he tends to work in the signal domain and derive his control messages.
Any other ideas for a *reliable* detection of phase reset?
On Fri, 1 Dec 2006 22:35:24 +0900 "hard off" hard.off@gmail.com wrote:
i want a phasor~ to send a bang when the signal reaches 1. any ideas?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
hard off -
Jamie Bullock -
marius schebella -
padawan12 -
Steffen