Is it possible to synchronize snapshot~ objects?

Aug 12, 2007 at 2:13am

Is it possible to synchronize snapshot~ objects?

I’m working on some visualizations where I need to check the values of 2 different signals at the exact same sample. I was hoping to use snapshot~ objects, but I can’t find any way to synchronize them.

Here’s a simple example patch to show the lack of synchronization using one input signal to 2 different snapshot objects:

#P window setfont “Sans Serif” 9.;
#P flonum 202 224 282 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 204 191 27 9109513 – 0.;
#P newex 203 99 64 9109513 cycle~ 10000;
#P newex 251 146 69 9109513 snapshot~ 100;
#P toggle 191 308 15 0;
#P newex 170 144 69 9109513 snapshot~ 100;
#P newex 191 327 28 9109513 dac~;
#P connect 4 0 1 0;
#P connect 4 0 3 0;
#P connect 3 0 5 1;
#P connect 1 0 5 0;
#P connect 5 0 6 0;
#P connect 2 0 0 0;
#P window clipboard copycount 7;

Has anyone else run into this being a problem?

#33221
Aug 12, 2007 at 3:49am

At 8:13 PM -0600 8/11/07, Aaron Faulstich wrote:
>I’m working on some visualizations where I need to check the values of 2 different signals at the exact same sample. I was hoping to use snapshot~ objects, but I can’t find any way to synchronize them.

Turn off the internal clock, and clock them all from a single source.

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#110382
Aug 12, 2007 at 4:35am

use the clock message and check out setclock
On Aug 11, 2007, at 11:49 PM, Chris Muir wrote:

> At 8:13 PM -0600 8/11/07, Aaron Faulstich wrote:
>> I’m working on some visualizations where I need to check the
>> values of 2 different signals at the exact same sample. I was
>> hoping to use snapshot~ objects, but I can’t find any way to
>> synchronize them.
>
> Turn off the internal clock, and clock them all from a single source.
>
> -C
>
> —
> Chris Muir | “There are many futures and only one status
> quo.
> cbm@well.com | This is why conservatives mostly agree,
> http://www.xfade.com | and radicals always argue.” – Brian Eno

v a d e //

http://www.vade.info
abstrakt.vade.info

#110383
Aug 12, 2007 at 5:49am

Thank you guys, that’s just what I needed.

Is there anything similar I can do with multiple average~ objects to make sure they are synchronized in the sets of samples they use?
I can’t seem to get multiple peakamp~ objects in sync, either.

#110384
Aug 12, 2007 at 7:28am

At 11:49 PM -0600 8/11/07, Aaron Faulstich wrote:
>Is there anything similar I can do with multiple average~ objects to make sure they are synchronized in the sets of samples they use?

I’m not sure you can sync average~, but I bet it won’t be too far off, on average.

>I can’t seem to get multiple peakamp~ objects in sync, either.

peakamp will report the current peak with a bang in the left inlet. Don’t use an argument to set a time interval.

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#110385
Aug 12, 2007 at 3:09pm

The average~ objects aren’t too far off, but they are off. I’m trying to avoid all errors.

I’m using a metro object to bang 2 peakamp~ objects, and the results of sending the same signal to both peakamp~ objects is not always the same. To me this would imply that they are not synchronized, but I may be overlooking something. Here is an example patch that sums the error between two peakamp~ objects over time:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 133 465 34 9109513 abs 0.;
#P toggle 225 456 15 0;
#P newex 224 481 28 9109513 dac~;
#P flonum 131 578 237 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 132 550 33 9109513 * 100.;
#P message 105 503 14 9109513 0;
#P newex 132 498 27 9109513 + 0.;
#P newex 132 525 27 9109513 f;
#P newex 133 440 27 9109513 – 0.;
#P newex 181 414 51 9109513 peakamp~;
#P newex 72 417 51 9109513 peakamp~;
#P newex 123 390 45 9109513 metro 10;
#P toggle 124 370 15 0;
#P message 99 354 14 9109513 1;
#P message 65 356 28 9109513 open;
#N sfplay~ 1 120960 0 ;
#P newobj 71 386 40 9109513 sfplay~;
#P comment 47 504 54 9109513 reset sum;
#P connect 8 0 16 0;
#P connect 16 0 10 0;
#P connect 2 0 1 0;
#P connect 3 0 1 0;
#P connect 5 0 6 0;
#P connect 1 0 6 0;
#P connect 1 1 3 0;
#P connect 4 0 5 0;
#P connect 12 0 13 0;
#P connect 10 0 9 0;
#P connect 11 0 9 0;
#P connect 9 0 12 0;
#P connect 6 0 8 0;
#P connect 9 0 10 1;
#P connect 7 0 8 1;
#P connect 5 0 7 0;
#P connect 1 0 7 0;
#P connect 15 0 14 0;
#P window clipboard copycount 17;

On my system error accumulates in spurts. That is, no error will be picked up for a number of minutes, but then a surge of multiple errors will occur in a short span of time.

#110386
Aug 12, 2007 at 4:37pm

comparing samples using snapshot~ is paradox, i dont see why you wouldnt like to do it on the signal layer.

#110387
Aug 13, 2007 at 2:25am

It’s for an XY-type scope done in openGL, and some future projects. If I could compare samples on the signal layer and then get that data out for visualization it would be great, but I haven’t figured out an adequate method for doing so.

My error-checking patch is actually giving me errors for two snapshot~ objects clocked by the same metro object, but fewer errors than what I get from peakamp~ objects.

#110388
Aug 13, 2007 at 2:32am

have you tried jit.poke~? You could write the samples to a matrix and
draw them with jit.gl.mesh.

wes

On 8/12/07, Aaron Faulstich wrote:
>
> It’s for an XY-type scope done in openGL, and some future projects. If I could compare samples on the signal layer and then get that data out for visualization it would be great, but I haven’t figured out an adequate method for doing so.
>
> My error-checking patch is actually giving me errors for two snapshot~ objects clocked by the same metro object, but fewer errors than what I get from peakamp~ objects.
>
>

#110389
Aug 14, 2007 at 1:30am

The main use for this was originally to analyze compression characteristics, so I wanted to use it with peakamp~ and average~ objects. If I can’t get those in sync then I’m not sure if I could come up with something involving jit.poke~ that would improve it.

Here’s the patch so far (minus all the objects I have just for watching errors at the various stages).

#P window setfont “Sans Serif” 18.;
#P window linecount 1;
#P comment 496 60 16 9109522 Y;
#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P comment 741 62 100 9109513 play audio file into two different peakamp~ objects;
#P window linecount 1;
#P newex 427 202 72 9109513 pack 0. 0. 0. 0.;
#P newex 508 129 43 9109513 deferlow;
#P button 491 131 15 0;
#P newex 482 157 27 9109513 f;
#P newex 443 129 43 9109513 deferlow;
#P button 426 131 15 0;
#P newex 430 100 60 9109513 unpack 0. 0.;
#P newex 428 160 27 9109513 f;
#P newex 741 114 51 9109513 peakamp~;
#P newex 632 117 51 9109513 peakamp~;
#P newex 683 90 45 9109513 metro 10;
#P toggle 684 70 15 0;
#P newex 465 39 27 9109513 – 1.;
#P newex 465 21 27 9109513 * 2.;
#P newex 417 39 27 9109513 – 1.;
#P newex 417 21 27 9109513 * 2.;
#P message 675 46 14 9109513 1;
#P message 625 56 28 9109513 open;
#N sfplay~ 1 120960 0 ;
#P newobj 631 86 40 9109513 sfplay~;
#P message 427 221 147 9109513 reset , moveto $1 $2 , lineto $3 $4;
#P toggle 615 352 15 0;
#P newex 615 370 28 9109513 dac~;
#P newex 430 82 50 9109513 pack 0. 0.;
#P newex 145 235 96 9109513 jit.slide @slide_up 15;
#P user jit.pwindow 144 256 258 258 1 1 0 0 1 0;
#P newex 145 199 50 9109513 qmetro 10;
#P toggle 174 116 15 0;
#P newex 175 141 50 9109513 qmetro 10;
#P newex 145 217 129 9109513 jit.matrix junk 4 char 256 256;
#P newex 175 177 219 9109513 jit.gl.render junk @ortho 2 @erase_color 1. 1. 1. 1.;
#P newex 175 159 45 9109513 t b erase;
#P newex 427 238 220 9109513 jit.gl.sketch junk @color 0. 0. 0. 1. @line_width 4.;
#P window linecount 2;
#P comment 315 26 100 9109513 put amplitudes into -1 to 1 range for display;
#P window setfont “Sans Serif” 18.;
#P window linecount 1;
#P comment 399 62 16 9109522 X;
#P connect 7 0 8 0;
#P connect 8 0 5 0;
#P connect 5 0 10 0;
#P connect 10 0 9 0;
#P connect 7 0 6 0;
#P connect 6 0 3 0;
#P connect 3 1 4 0;
#P connect 3 0 4 0;
#P connect 24 0 18 0;
#P connect 18 0 19 0;
#P connect 27 0 28 0;
#P connect 26 0 33 0;
#P connect 33 0 14 0;
#P connect 14 0 2 0;
#P connect 28 0 26 0;
#P connect 19 0 11 0;
#P connect 11 0 27 0;
#P connect 27 0 29 0;
#P connect 29 0 26 1;
#P connect 30 0 33 1;
#P connect 25 0 20 0;
#P connect 20 0 21 0;
#P connect 27 0 33 2;
#P connect 21 0 11 1;
#P connect 31 0 30 0;
#P connect 27 1 33 3;
#P connect 27 1 31 0;
#P connect 32 0 30 1;
#P connect 27 1 32 0;
#P connect 13 0 12 0;
#P connect 17 0 15 0;
#P connect 16 0 15 0;
#P connect 23 0 24 0;
#P connect 15 0 24 0;
#P connect 15 1 17 0;
#P connect 22 0 23 0;
#P connect 17 0 22 0;
#P connect 23 0 25 0;
#P connect 15 0 25 0;
#P window clipboard copycount 36;

#110390
Aug 14, 2007 at 11:18am

Aaron Faulstich skrev:
> The main use for this was originally to analyze compression characteristics, so I wanted to use it with peakamp~ and average~ objects. If I can’t get those in sync then I’m not sure if I could come up with something involving jit.poke~ that would improve it.
>
Hi Aaron,
I think the problem of your patch is that you are trying to sync audio
inputs with a scheduler-rate metro system. Here’s a patch that somewhat
demonstrates the issue;

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 563 251 43 9109513 deferlow;
#P newex 518 251 43 9109513 deferlow;
#P flonum 461 90 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 461 110 59 9109513 phasor~ 220;
#P window setfont “Sans Serif” 18.;
#P comment 575 201 16 9109522 Y;
#P window setfont “Sans Serif” 9.;
#P window linecount 9;
#P comment 610 93 188 9109513 using scheduler-rate metro to sample
signal-rate audio will inevitably lead to “sampling errors” as audio
frequencies change faster. This is clearly visible in this version ,
where we see a large jump when the first peakamp~ sees the top of the
phasor~ wave , and the second sees the bottom , causing a large line
instead of a small blip.;
#P window linecount 1;
#P newex 503 275 72 9109513 pack 0. 0. 0. 0.;
#P newex 503 223 60 9109513 unpack 0. 0.;
#P newex 543 138 51 9109513 peakamp~;
#P newex 474 138 51 9109513 peakamp~;
#P newex 543 110 45 9109513 metro 10;
#P toggle 543 90 15 0;
#P newex 543 183 27 9109513 – 1.;
#P newex 543 165 27 9109513 * 2.;
#P newex 503 183 27 9109513 – 1.;
#P newex 503 165 27 9109513 * 2.;
#P message 503 295 147 9109513 reset , moveto $1 $2 , lineto $3 $4;
#P toggle 354 194 15 0;
#P newex 354 212 28 9109513 dac~;
#P newex 503 205 50 9109513 pack 0. 0.;
#P newex 166 196 118 9109513 jit.window junk @floating 1;
#P toggle 166 86 15 0;
#P newex 166 104 50 9109513 qmetro 10;
#P newex 166 140 219 9109513 jit.gl.render junk @ortho 2 @erase_color 1.
1. 1. 1.;
#P newex 166 122 45 9109513 t b erase;
#P newex 503 313 220 9109513 jit.gl.sketch junk @color 0. 0. 0. 1.
@line_width 4.;
#P window setfont “Sans Serif” 18.;
#P comment 471 199 16 9109522 X;
#P fasten 23 0 17 0 466 133 479 133;
#P fasten 23 0 18 0 466 132 548 132;
#P fasten 19 1 20 1 558 246 528 246;
#P fasten 19 1 26 0 558 246 568 246;
#P connect 19 0 20 0;
#P fasten 19 0 25 0 508 246 523 246;
#P fasten 16 0 17 0 548 132 479 132;
#P connect 16 0 18 0;
#P connect 24 0 23 0;
#P connect 26 0 20 3;
#P fasten 25 0 20 2 523 272 548 272;
#P connect 5 0 4 0;
#P connect 15 0 16 0;
#P connect 9 0 8 0;
#P connect 14 0 7 1;
#P connect 13 0 14 0;
#P connect 18 0 13 0;
#P connect 7 0 19 0;
#P connect 12 0 7 0;
#P connect 10 0 1 0;
#P connect 20 0 10 0;
#P connect 11 0 12 0;
#P fasten 17 0 11 0 479 160 508 160;
#P connect 2 0 3 0;
#P connect 2 1 3 0;
#P connect 4 0 2 0;
#P window clipboard copycount 27;

#110391
Aug 14, 2007 at 5:10pm

Thank you for putting that patch together.

I think I am not being clear enough as to what is the problem. I’ve designed this to make continuous connected line segments emulating a slow trace on an oscilloscope. I was using jit.slide to make the graph even more “continuous”

The problem for me is that I get discrepancies between the peakamp~ objects that cause bumps (deviations from the straight diagonal line in your patch) when I’m trying to get a transfer function. The text in your patch sounds to me like you’re comparing a discontinuity from high frequency content to errors in timing, and I’m not sure what your intention is. Your patch does exactly what I would expect, creating small blips followed by a large line segment at the discontinuity. The discontinuity is not a timing problem, it is part of the signal.

This is made for looking at relatively low-frequency, continous signals, so graphical aliasing and high frequency response are an afterthought.

Here’s a working non-amplitude version of the original patch to show the kind of thing for which I want to use it.

#P window setfont “Sans Serif” 9.;
#P flonum 656 94 35 9 0. 1. 3 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P comment 545 77 100 9109513 3: dueling oscillators;
#P comment 545 61 100 9109513 2: clipping;
#P newex 605 118 60 9109513 cycle~ 1 0.4;
#P number 496 50 35 9 1 3 3 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 536 117 62 9109513 clip~ -0.5 0.5;
#P newex 488 163 54 9109513 selector~ 3;
#P newex 498 111 28 9109513 *~ 3.;
#P newex 498 129 31 9109513 tanh~;
#P newex 447 193 51 9109513 snapshot~;
#P newex 498 193 51 9109513 snapshot~;
#P newex 418 79 44 9109513 cycle~ 1;
#P window setfont “Sans Serif” 18.;
#P comment 530 263 16 9109522 Y;
#P window setfont “Sans Serif” 9.;
#P comment 545 45 100 9109513 1: tanh function;
#P newex 456 381 72 9109513 pack 0. 0. 0. 0.;
#P newex 537 308 43 9109513 deferlow;
#P button 520 310 15 0;
#P newex 511 336 27 9109513 f;
#P newex 472 308 43 9109513 deferlow;
#P button 455 310 15 0;
#P newex 459 279 60 9109513 unpack 0. 0.;
#P newex 457 339 27 9109513 f;
#P newex 418 174 45 9109513 metro 10;
#P toggle 419 154 15 0;
#P message 456 400 147 9109513 reset , moveto $1 $2 , lineto $3 $4;
#P toggle 505 455 15 0;
#P newex 505 473 28 9109513 dac~;
#P newex 459 261 50 9109513 pack 0. 0.;
#P newex 145 235 96 9109513 jit.slide @slide_up 15;
#P user jit.pwindow 83 262 258 258 1 1 0 0 1 0;
#P newex 145 199 50 9109513 qmetro 10;
#P toggle 174 116 15 0;
#P newex 175 141 50 9109513 qmetro 10;
#P newex 145 217 129 9109513 jit.matrix junk 4 char 256 256;
#P newex 175 177 219 9109513 jit.gl.render junk @ortho 2 @erase_color 1. 1. 1. 1.;
#P newex 175 159 45 9109513 t b erase;
#P newex 456 417 220 9109513 jit.gl.sketch junk @color 0. 0. 0. 1. @line_width 4.;
#P window setfont “Sans Serif” 18.;
#P comment 429 265 16 9109522 X;
#P window setfont “Sans Serif” 14.;
#P window linecount 2;
#P comment 435 31 100 9109518 pick a transfer function:;
#P connect 10 0 9 0;
#P connect 7 0 8 0;
#P connect 8 0 5 0;
#P connect 5 0 10 0;
#P connect 7 0 6 0;
#P connect 6 0 3 0;
#P connect 3 0 4 0;
#P connect 3 1 4 0;
#P connect 15 0 16 0;
#P connect 27 0 29 0;
#P connect 16 0 29 0;
#P connect 18 0 19 0;
#P connect 17 0 24 0;
#P connect 24 0 14 0;
#P connect 14 0 2 0;
#P connect 19 0 17 0;
#P connect 29 0 11 0;
#P connect 11 0 18 0;
#P connect 18 0 20 0;
#P connect 20 0 17 1;
#P connect 21 0 24 1;
#P connect 34 0 32 0;
#P connect 18 0 24 2;
#P connect 27 0 31 0;
#P connect 31 0 30 0;
#P connect 32 0 28 0;
#P connect 16 0 28 0;
#P connect 28 0 11 1;
#P connect 30 0 32 1;
#P connect 13 0 12 0;
#P connect 22 0 21 0;
#P connect 33 0 32 2;
#P connect 18 1 24 3;
#P connect 18 1 22 0;
#P connect 23 0 21 1;
#P connect 35 0 32 3;
#P connect 27 0 33 0;
#P connect 18 1 23 0;
#P connect 38 0 35 1;
#P window clipboard copycount 39;

I would like to eventually analyze the amplitude envelopes of signals, but when I replace snapshot~ with peakamp~ the patch no longer works correctly. Additionally, replacing snapshot~ with a combination of average~ and snapshot~ also does not work. Both of those methods create many errors that show up as jagged edges in the graph.

#110392
Aug 14, 2007 at 6:14pm

as was mentioned, the problem is trying to sync audio signals with a schedular rate timing mechanism.
the key is to stay in the audio domain.
jit.poke~ does this for you.
patch below. this can be adapted to use opengl if necessary.
-rob

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 551 284 14 196617 1;
#P newex 503 283 48 196617 loadbang;
#P message 552 313 26 196617 rms;
#P message 459 313 39 196617 bipolar;
#P message 503 313 45 196617 absolute;
#P newex 409 359 52 196617 average~;
#P newex 463 358 52 196617 average~;
#P newex 86 127 36 196617 edge~;
#P newex 83 105 65 196617 >~ 0.9999;
#P newex 355 403 38 196617 sig~ 1;
#P newex 463 402 44 196617 +~ 120.;
#P newex 463 380 42 196617 *~ 120;
#P newex 409 402 44 196617 +~ 160.;
#P newex 409 380 45 196617 *~ 160.;
#P message 86 151 31 196617 clear;
#P newex 27 151 59 196617 metro 10;
#P toggle 28 131 15 0;
#P newex 355 428 118 196617 jit.poke~ bar 2 2;
#B color 5;
#P user jit.pwindow 26 205 322 242 0 1 0 0 1 0;
#P newex 27 180 145 196617 jit.matrix bar 4 char 320 240;
#P flonum 609 199 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 545 77 100 196617 3: dueling oscillators;
#P comment 545 61 100 196617 2: clipping;
#P newex 558 223 74 196617 cycle~ 1 0.4;
#P number 420 168 35 9 1 3 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 512 204 81 196617 clip~ -0.5 0.5;
#P newex 420 255 149 196617 selector~ 3;
#P newex 466 204 42 196617 *~ 3.;
#P newex 466 222 31 196617 tanh~;
#P newex 83 70 44 196617 cycle~ 1;
#P comment 545 45 100 196617 1: tanh function;
#P toggle 546 96 15 0;
#P newex 546 114 28 196617 dac~;
#P window setfont “Sans Serif” 14.;
#P window linecount 2;
#P comment 429 49 119 196622 pick a transfer function:;
#P hidden connect 33 0 9 0;
#P connect 32 0 29 0;
#P connect 32 0 33 0;
#P connect 13 0 10 1;
#P connect 10 0 7 3;
#P connect 2 0 1 0;
#P connect 8 0 7 2;
#P connect 4 0 25 0;
#P fasten 4 0 28 0 88 99 414 99;
#P fasten 4 0 6 0 88 99 471 99;
#P fasten 4 0 8 0 88 99 517 99;
#P connect 5 0 7 1;
#P connect 6 0 5 0;
#P connect 23 0 16 2;
#P connect 22 0 23 0;
#P connect 27 0 22 0;
#P fasten 7 0 27 0 425 293 468 293;
#P connect 29 0 28 0;
#P connect 29 0 27 0;
#P connect 30 0 27 0;
#P connect 31 0 28 0;
#P connect 31 0 27 0;
#P connect 9 0 7 0;
#P connect 21 0 16 1;
#P connect 20 0 21 0;
#P connect 28 0 20 0;
#P connect 30 0 28 0;
#P connect 24 0 16 0;
#P connect 26 0 19 0;
#P connect 25 0 26 0;
#P connect 14 0 15 0;
#P connect 18 0 14 0;
#P connect 19 0 14 0;
#P connect 17 0 18 0;
#P window clipboard copycount 34;

#110393
Aug 14, 2007 at 7:29pm

Aaron Faulstich skrev:
> Thank you for putting that patch together.
>
> I think I am not being clear enough as to what is the problem. I’ve designed this to make continuous connected line segments emulating a slow trace on an oscilloscope. I was using jit.slide to make the graph even more “continuous”
>
> The problem for me is that I get discrepancies between the peakamp~ objects that cause bumps (deviations from the straight diagonal line in your patch) when I’m trying to get a transfer function. The text in your patch sounds to me like you’re comparing a discontinuity from high frequency content to errors in timing, and I’m not sure what your intention is. Your patch does exactly what I would expect, creating small blips followed by a large line segment at the discontinuity. The discontinuity is not a timing problem, it is part of the signal.
The discontinuity *is* a timing problem. If one peakamp~ measures close
to 1., the other one, ideally, should also measure close to 1., since
they should, “ideall” both be triggered as close to instantaneously as
possible. Instead one peakamp~ is triggered, but before the next one can
be triggered by the lower-than-signal-rate scheduler timing the phasor~
has returned to 0., showing the abrupt change from 1. to 0. as a
downward line.

I’m sorry I couldn’t properly convey my analysis of your problem, Aaron.
Hopefully someone else can explain it better than I.

Good luck.
Andreas.

#110394
Aug 14, 2007 at 7:51pm

>The discontinuity *is* a timing problem.

phasor~ is by its very nature discontinuous, in the same way that true square waves are discontinuous. Maybe we’re using the word for different meanings, but I’m using it in the mathematical sense that a jump directly from 1 to 0 is a discontinuity.

I think I know what you’re trying to say, but the timing discrepancy you are describing would show up on an XY scope as either a purely vertical (Y resets before X) or horizontal (X resets before Y) jump. Because the jump is diagonal, it means X and Y are resetting at the same time. There is never a point that shows up on the graph with coordinates around 1, 0 or 0, 1 on my system.

I hope I don’t sound ungrateful. I really appreciate the time you took to make that patch and explain.

#110395
Aug 14, 2007 at 7:57pm

Thank you Rob, I see that jit.poke~ fixes the timing problem. How can I adapt that patch to show a continuous fading trace? My poor Jitter skills are failing me here.

#110396
Aug 14, 2007 at 8:34pm

How can this very slightly modified version of Rob’s patch be moved to openGL for further customization of the graphics (colors, widths, etc)?

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 29 209 107 9109513 jit.slide @slide_down 20;
#P flonum 580 171 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 371 45 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 551 284 14 9109513 1;
#P newex 503 283 48 9109513 loadbang;
#P message 552 313 26 9109513 rms;
#P message 459 313 39 9109513 bipolar;
#P message 503 313 45 9109513 absolute;
#P newex 409 359 52 9109513 average~;
#P newex 463 358 52 9109513 average~;
#P newex 355 403 38 9109513 sig~ 1;
#P newex 463 402 44 9109513 +~ 120.;
#P newex 463 380 42 9109513 *~ 120;
#P newex 409 402 44 9109513 +~ 160.;
#P newex 409 380 41 9109513 *~ -160.;
#P message 8 158 31 9109513 clear;
#P newex 37 136 59 9109513 metro 10;
#P toggle 38 116 15 0;
#P newex 355 428 118 9109513 jit.poke~ bar 2 2;
#B color 5;
#P user jit.pwindow 26 237 322 242 0 1 0 0 1 0;
#P newex 27 180 145 9109513 jit.matrix bar 4 char 320 240;
#P flonum 609 199 35 9 0. 1. 3 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 545 77 100 9109513 3: dueling oscillators;
#P comment 545 61 100 9109513 2: clipping;
#P newex 558 223 74 9109513 cycle~ 1 0.4;
#P number 420 168 35 9 1 3 3 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 512 204 81 9109513 clip~ -0.5 0.5;
#P newex 420 255 149 9109513 selector~ 3;
#P newex 466 204 42 9109513 *~ 3.;
#P newex 466 222 31 9109513 tanh~;
#P newex 373 70 44 9109513 cycle~ 1;
#P comment 545 45 100 9109513 1: tanh function;
#P toggle 546 96 15 0;
#P newex 546 114 28 9109513 dac~;
#P window setfont “Sans Serif” 14.;
#P window linecount 2;
#P comment 429 49 119 9109518 pick a transfer function:;
#P connect 18 0 19 0;
#P connect 18 0 14 0;
#P connect 19 0 14 0;
#P connect 34 0 15 0;
#P connect 14 0 34 0;
#P connect 17 0 18 0;
#P connect 24 0 16 0;
#P connect 32 0 4 0;
#P fasten 4 0 26 0 378 99 414 99;
#P connect 28 0 26 0;
#P connect 29 0 26 0;
#P connect 27 0 26 0;
#P connect 26 0 20 0;
#P connect 20 0 21 0;
#P connect 21 0 16 1;
#P hidden connect 31 0 9 0;
#P connect 9 0 7 0;
#P connect 28 0 25 0;
#P connect 29 0 25 0;
#P connect 27 0 25 0;
#P fasten 7 0 25 0 425 293 468 293;
#P connect 25 0 22 0;
#P connect 22 0 23 0;
#P connect 23 0 16 2;
#P fasten 4 0 6 0 378 99 471 99;
#P connect 6 0 5 0;
#P connect 5 0 7 1;
#P connect 30 0 27 0;
#P fasten 4 0 8 0 378 99 517 99;
#P connect 8 0 7 2;
#P connect 2 0 1 0;
#P connect 30 0 31 0;
#P connect 33 0 10 0;
#P connect 10 0 7 3;
#P connect 13 0 10 1;
#P window clipboard copycount 35;

#110397
Aug 14, 2007 at 8:58pm

hard to say.
the left input of jit.poke~ is the value of the cell. now, it is getting a continuous signal~ of 1. if you feed it something else like phasor~ or cycle~, it will fade in and out.

as wes suggested, you could use the values in the matrix with gl.mesh to get some nice visualizations.

check out some of andrew’s jitter recipes that deal with poke~ and gl rendering.

-rob

#110398
Aug 14, 2007 at 9:46pm

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 192 409 48 196617 loadbang;
#P newex 617 514 124 196617 jit.poke~ scopacetic2 2 1;
#B color 5;
#P newex 181 242 111 196617 jit.matrix scopacetic2;
#P newex 181 218 41 196617 r draw;
#P newex 181 296 259 196617 jit.gl.mesh test @draw_mode line_strip
@color 0 0 1 1;
#P newex 304 508 111 196617 jit.matrix scopacetic2;
#P newex 192 508 105 196617 jit.matrix scopacetic;
#P newex 192 456 186 196617 jit.matrix scopacetic 3 float32 2048 1;
#P newex 39 260 105 196617 jit.matrix scopacetic;
#P newex 39 236 41 196617 r draw;
#P newex 39 331 259 196617 jit.gl.mesh test @draw_mode line_strip
@color 1 0 0 1;
#P message 170 134 34 196617 reset;
#P newex 170 154 186 196617 jit.gl.handle test @inherit_transform 1;
#P newex 35 154 48 196617 r render;
#P toggle 150 125 15 0;
#N vpatcher 53 128 279 297;
#P inlet 106 30 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 43 95 47 196617 gate 1 1;
#P newex 42 116 41 196617 s draw;
#P window linecount 1;
#P newex 17 52 58 196617 t b b erase;
#P inlet 17 32 15 0;
#P outlet 17 83 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P fasten 2 2 0 0 70 75 22 75;
#P connect 4 0 3 0;
#P fasten 5 0 4 0 111 88 48 88;
#P fasten 2 1 4 1 46 83 85 83;
#P lcolor 15;
#P pop;
#P newobj 88 154 42 196617 p Draw;
#P toggle 226 93 15 0;
#P message 226 113 68 196617 fullscreen $1;
#N vpatcher 30 89 166 253;
#P window setfont “Sans Serif” 9.;
#P newex 50 71 35 196617 sel 27;
#P newex 50 50 40 196617 key;
#P outlet 50 93 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P pop;
#P newobj 243 93 33 196617 p Esc;
#P newex 226 131 151 196617 jit.window test @depthbuffer 1;
#P toggle 88 106 15 0;
#P newex 88 125 57 196617 qmetro 30;
#P newex 88 181 187 196617 jit.gl.render test @erase_color 0 0 0 1;
#P newex 577 481 41 196617 sig~ 0.;
#P comment 523 444 128 196617 each sample into a new cell;
#P newex 523 460 85 196617 count~ 0 2048 1;
#P comment 214 429 128 196617 create 3D coordinates;
#P button 192 429 15 0;
#P newex 192 482 170 196617 jit.expr @expr “snorm[0]” “0″ “0″;
#P flonum 640 231 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 431 105 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 611 344 14 196617 1;
#P newex 563 343 48 196617 loadbang;
#P message 612 373 26 196617 rms;
#P message 519 373 39 196617 bipolar;
#P message 563 373 45 196617 absolute;
#P newex 469 419 52 196617 average~;
#P newex 523 419 52 196617 average~;
#P newex 469 515 118 196617 jit.poke~ scopacetic 2 1;
#B color 5;
#P flonum 669 259 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 605 137 100 196617 3: dueling oscillators;
#P comment 605 121 100 196617 2: clipping;
#P newex 618 283 74 196617 cycle~ 1 0.4;
#P number 480 228 35 9 1 3 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 572 264 81 196617 clip~ -0.5 0.5;
#P newex 480 315 149 196617 selector~ 3;
#P newex 526 264 42 196617 *~ 3.;
#P newex 526 282 31 196617 tanh~;
#P newex 433 130 44 196617 cycle~ 1;
#P comment 605 105 100 196617 1: tanh function;
#P toggle 606 156 15 0;
#P newex 606 174 28 196617 dac~;
#P window setfont “Sans Serif” 14.;
#P window linecount 2;
#P comment 489 109 119 196622 pick a transfer function:;
#P connect 24 0 46 0;
#P fasten 24 0 47 0 197 503 309 503;
#P connect 52 0 25 0;
#P connect 50 0 48 0;
#P connect 44 0 42 0;
#P connect 29 0 14 2;
#P fasten 29 0 51 2 582 500 736 500;
#P connect 27 0 14 1;
#P fasten 27 0 51 1 528 509 679 509;
#P fasten 15 0 51 0 528 503 622 503;
#P connect 49 0 50 0;
#P connect 45 0 24 0;
#P connect 25 0 45 0;
#P connect 16 0 14 0;
#P connect 43 0 44 0;
#P connect 35 0 33 0;
#P connect 36 0 35 0;
#P connect 34 0 36 0;
#P connect 41 0 40 0;
#P fasten 38 0 37 1 155 147 125 147;
#P fasten 39 0 30 0 40 176 93 176;
#P connect 37 0 30 0;
#P fasten 40 0 30 0 175 176 93 176;
#P connect 31 0 37 0;
#P connect 32 0 31 0;
#P connect 13 0 10 1;
#P connect 10 0 7 3;
#P connect 23 0 10 0;
#P connect 20 0 17 0;
#P connect 20 0 21 0;
#P connect 2 0 1 0;
#P connect 8 0 7 2;
#P fasten 4 0 16 0 438 159 474 159;
#P fasten 4 0 6 0 438 159 531 159;
#P fasten 4 0 8 0 438 159 577 159;
#P connect 5 0 7 1;
#P connect 6 0 5 0;
#P fasten 7 0 15 0 485 353 528 353;
#P connect 17 0 16 0;
#P connect 17 0 15 0;
#P connect 19 0 15 0;
#P connect 18 0 16 0;
#P connect 18 0 15 0;
#P connect 9 0 7 0;
#P hidden connect 21 0 9 0;
#P connect 19 0 16 0;
#P connect 22 0 4 0;
#P window clipboard copycount 53;

#110399
Aug 14, 2007 at 9:48pm

Aaron Faulstich skrev:
> How can this very slightly modified version of Rob’s patch be moved to openGL for further customization of the graphics (colors, widths, etc)?
How about just using the “classic” method of jit.catch~ -> jit.gl.graph
? The jit.gl.graph help file gives a pretty straightforward view of
openGL visualisation.

Andreas.

#110400
Aug 15, 2007 at 1:19am

Thanks guys, you’ve given me enough learning material to keep me busy for a while now : )
I only recently bought Jitter, so I feel like I’m starting all over again with new concepts.

I’ll post back after I’ve assimilated all the suggestions and put them to use.

#110401

You must be logged in to reply to this topic.