Is it possible to synchronize snapshot~ objects?


    Aug 12 2007 | 2:13 am
    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?

    • Aug 12 2007 | 3:49 am
      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
    • Aug 12 2007 | 4:35 am
      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 //
      www.vade.info
      abstrakt.vade.info
    • Aug 12 2007 | 5:49 am
      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.
    • Aug 12 2007 | 7:28 am
      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
    • Aug 12 2007 | 3:09 pm
      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.
    • Aug 12 2007 | 4:37 pm
      comparing samples using snapshot~ is paradox, i dont see why you wouldnt like to do it on the signal layer.
    • Aug 13 2007 | 2:25 am
      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.
    • Aug 13 2007 | 2:32 am
      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.
      >
      >
    • Aug 14 2007 | 1:30 am
      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).
    • Aug 14 2007 | 11:18 am
      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;
    • Aug 14 2007 | 5:10 pm
      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.
    • Aug 14 2007 | 6:14 pm
      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
    • Aug 14 2007 | 7:29 pm
      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.
    • Aug 14 2007 | 7:51 pm
      >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.
    • Aug 14 2007 | 7:57 pm
      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.
    • Aug 14 2007 | 8:34 pm
      How can this very slightly modified version of Rob's patch be moved to openGL for further customization of the graphics (colors, widths, etc)?
    • Aug 14 2007 | 8:58 pm
      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
    • Aug 14 2007 | 9:46 pm
    • Aug 14 2007 | 9:48 pm
      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.
    • Aug 15 2007 | 1:19 am
      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.