skrasms

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:

Has anyone else run into this being a problem?

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. 

Has anyone else run into this being a problem?


is-it-possible-to-synchronize-snapshot-objects

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.

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

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.

-- 
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


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 

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

> Chris Muir | "There are many futures and only one status 

> cbm@well.com | This is why conservatives mostly agree,

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

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.

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.


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.

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?

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:

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.

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

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.

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.


have you tried jit.poke~? You could write the samples to a matrix and

> 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.

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

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.
>
>


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).

> 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.

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 

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;

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.

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.

Thank you for putting that patch together. 

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.


as was mentioned, the problem is trying to sync audio signals with a schedular rate timing mechanism.

patch below. this can be adapted to use opengl if necessary.

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

> 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 

I'm sorry I couldn't properly convey my analysis of your problem, Aaron. 

Hopefully someone else can explain it better than I.

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.

>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.

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.

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

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.

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.

> 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 

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.

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.

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.


Is it possible to synchronize snapshot~ objects?