Re: [PD] bang when phasor~ reaches 1
On 02/12/2006, at 10.30, Frank Barknecht wrote: However with the metro it will be much easier to know when the fake phasor reaches 1 or 0. That's what bang'ed my question. Thanks for explaining. Bets, Steffen ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
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__ #N canvas 377 467 551 486 10; #X obj 108 18 loadbang; #X obj 54 130 f \$1; #X obj 54 17 inlet; #X obj 54 385 vline~; #X obj 54 257 t b b; #X obj 157 405 outlet; #X obj 181 17 inlet; #X text 231 17 reset phase; #X obj 53 408 outlet~; #X obj 54 100 abs; #X obj 126 176 expr 1000/$f1; #X obj 54 150 t a a; #X obj 54 238 metro; #X obj 126 202 t a a; #X msg 181 58 bang; #X obj 286 126 0; #X obj 286 156 select 1 0; #X obj 54 285 f; #X obj 54 318 list append 0 1; #X msg 54 355 \$2 \, \$3 \$1; #X msg 286 180 1 0; #X msg 318 181 0 1; #X obj 54 56 t a a; #X text 370 156 up-down/down-up; #X connect 0 0 1 0; #X connect 1 0 11 0; #X connect 2 0 22 0; #X connect 3 0 8 0; #X connect 4 0 17 0; #X connect 4 1 5 0; #X connect 6 0 14 0; #X connect 9 0 1 0; #X connect 10 0 13 0; #X connect 11 0 12 0; #X connect 11 1 10 0; #X connect 12 0 4 0; #X connect 13 0 12 1; #X connect 13 1 17 1; #X connect 14 0 12 0; #X connect 15 0 16 0; #X connect 16 0 20 0; #X connect 16 1 21 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 19 0 3 0; #X connect 20 0 18 1; #X connect 21 0 18 1; #X connect 22 0 9 0; #X connect 22 1 15 0; #N canvas 224 127 673 486 10; #N canvas 267 211 916 531 phasesyncronousdrums 0; #X obj 283 98 / 60; #X obj 282 138 * -1; #N canvas 0 0 450 300 psbd 0; #X obj 167 30 wrap~; #X obj 182 230 *~; #X obj 168 55 *~; #X obj 183 146 osc~; #X obj 167 82 *~; #X obj 198 208 lop~ 100; #X obj 168 5 inlet~; #X obj 181 166 clip~ -0.9 0.9; #X obj 184 124 +~ 44; #X obj 184 104 *~ 44; #X obj 182 189 *~ 2; #X obj 177 260 outlet~; #X connect 0 0 2 0; #X connect 0 0 2 1; #X connect 1 0 11 0; #X connect 2 0 4 0; #X connect 2 0 4 1; #X connect 2 0 9 0; #X connect 3 0 7 0; #X connect 4 0 5 0; #X connect 5 0 1 1; #X connect 6 0 0 0; #X connect 7 0 10 0; #X connect 8 0 3 0; #X connect 9 0 8 0; #X connect 10 0 1 0; #X restore 203 335 pd psbd; #N canvas 0 0 501 413 pssd 0; #X obj 189 1 wrap~; #X obj 352 121 noise~; #X obj 198 343 *~; #X obj 188 26 *~; #X obj 187 53 *~; #X obj 197 280 vcf~ 6000 3; #X obj 269 238 loadbang; #X obj 188 -41 inlet~; #X obj 289 154 +~; #X obj 288 101 +~ 100; #X obj 288 123 osc~; #X obj 288 78 *~ 100; #X obj 288 177 clip~ -0.3 0.3; #X obj 232 205 *~ 8000; #X obj 200 84 *~; #X obj 232 225 +~ 700; #X msg 269 259 0.4; #X obj 198 303 *~ 1; #X obj 194 372 outlet~; #X connect 0 0 3 0; #X connect 0 0 3 1; #X connect 0 0 11 0; #X connect 1 0 8 1; #X connect 2 0 18 0; #X connect 3 0 4 0; #X connect 3 0 4 1; #X connect 4 0 2 1; #X connect 4 0 14 0; #X connect 4 0 14 1; #X connect 5 0 17 0; #X connect 6 0 16 0; #X connect 7 0 0 0; #X connect 8 0 12 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 9 0; #X connect 12 0 5 0; #X connect 13 0 15 0; #X connect 14 0 13 0; #X connect 15 0 5 1; #X connect 16 0 5 2; #X connect 17 0 2 0; #X restore 298 334 pd pssd; #X obj 283 184 *~ 8; #X obj 25 242 clip~ 0 1; #X obj 101 242 clip~ 1 2; #X obj 179 242 clip~ 2 3; #X obj 257 242 clip~ 3 4; #X obj 341 241 clip~ 4 5; #X obj 417 241 clip~ 5 6; #X obj 494 241 clip~ 6 7; #X obj 570 241 clip~ 7 8; #X obj 282 118 / 4; #N canvas 0 0 450 300 pshh 0; #X obj 199 386 wrap~; #X obj 216 507 noise~; #X obj 214 595 *~; #X obj 198 411 *~; #X obj 213 555 *~ 0.3; #X obj 213 532 vcf~ 6000 3; #X obj 285 490 loadbang; #X obj 198 344 inlet~; #X msg 285 511 6; #X obj 214 460
Re: [PD] bang when phasor~ reaches 1
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: http://puredata.hurleur.com/viewtopic.php?pid=2494#p2494 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
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__ #N canvas 326 164 736 482 10; #N canvas 0 0 450 300 bm 0; #X restore 218 423 pd bm; #X obj 100 381 s pd-bm; #X msg 220 349 clear; #X obj 100 269 until; #X obj 100 200 t b b; #X floatatom 210 154 5 0 0 2 howmany - -; #X obj 100 146 bng 32 250 50 0 empty empty test-x 0 -6 0 8 -24198 -1 -1; #X obj 100 294 f 10; #X obj 133 293 + 20; #X msg 144 269 10; #X obj 494 248 until; #X obj 435 150 bng 24 250 50 0 empty empty run_test 0 -6 0 8 -225271 -1 -1; #X floatatom 435 297 8 0 0 1 milliseconds - -; #X obj 435 182 t b b b; #X obj 435 243 t b b; #X obj 435 274 cputime; #X obj 494 274 s BANG; #X floatatom 531 206 5 0 0 0 - - -; #X obj 100 327 pack 0 s; #X obj 211 268 list; #X symbolatom 211 291 10 0 0 0 - - -; #X msg 100 348 obj 10 \$1 \$2; #X text 211 185 Which?; #X text 25 22 first select \, which and how many objects to create \, then create them in [pd bm] by pressing the big green bng. After that \, send the test data by the run_test-bng and watch the time it takes.; #X msg 212 211 b-calc; #X msg 211 231 e-calc; #X obj 494 226 f 1; #X obj 100 244 f 100; #X msg 284 213 e-complex; #X msg 285 233 b-complex; #X connect 2 0 1 0; #X connect 3 0 7 0; #X connect 4 0 27 0; #X connect 4 1 2 0; #X connect 4 1 9 0; #X connect 5 0 27 1; #X connect 6 0 4 0; #X connect 7 0 8 0; #X connect 7 0 18 0; #X connect 8 0 7 1; #X connect 9 0 7 1; #X connect 10 0 16 0; #X connect 11 0 13 0; #X connect 13 0 14 0; #X connect 13 1 26 0; #X connect 13 2 14 0; #X connect 14 0 15 0; #X connect 14 1 15 1; #X connect 15 0 12 0; #X connect 17 0 26 1; #X connect 18 0 21 0; #X connect 19 0 20 0; #X connect 20 0 18 1; #X connect 21 0 1 0; #X connect 24 0 19 0; #X connect 25 0 19 0; #X connect 26 0 10 0; #X connect 27 0 3 0; #X connect 28 0 19 0; #X connect 29 0 19 0; #N canvas 231 180 450 300 10; #X obj 97 54 r BANG; #X obj 97 135 f; #X obj 97 103 expr 1000/$f1; #X obj 97 80 f 12; #X connect 0 0 3 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #N canvas 384 267 450 300 10; #X obj 87 90 r BANG; #X obj 87 127 expr 12*(1+2+3+4+5+6+7+8+9+10); #X obj 87 158 f; #X connect 0 0 1 0; #X connect 1 0 2 0; #N canvas 631 289 450 300 10; #X obj 143 191 f; #X obj 143 44 r BANG; #X obj 143 132 f 1000; #X obj 143 68 f 12; #X obj 143 97 t b a; #X obj 143 158 /; #X connect 1 0 3 0; #X connect 2 0 5 0; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 4 1 5 1; #X connect 5 0 0 0; #N canvas 0 0 450 300 10; #X obj 224 224 * 12; #X obj 144 88 f 1; #X obj 144 111 + 2; #X obj 154 121 + 3; #X obj 164 131 + 4; #X obj 174 141 + 5; #X obj 184 151 + 6; #X obj 196 160 + 7; #X obj 204 171 + 8; #X obj 215 181 + 9; #X obj 224 201 + 10; #X obj 144 58 r BANG; #X obj 222 244 f; #X connect 0 0 12 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 10 0; #X connect 10 0 0 0; #X connect 11 0 1 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
Hallo, padawan12 hat gesagt: // padawan12 wrote: Cool! We've discovered something very wrong. Maybe not, read on. Here I get number bcalcecalcbcplxecplx 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 2562780 2320 512 10430 5800 Now I'm wondering, if something became very wrong with [expr] ... Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] bang when phasor~ reaches 1
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
Re: [PD] bang when phasor~ reaches 1
[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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
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 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
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
