jit.slide - a little confused about the finer points...

    Aug 17 2012 | 11:14 am
    The jit.slide reference says:
    Given a slide value of 10, the slide up/down value output will only change 1/10th as quickly as the input.
    First of all, what does it mean by "1/10th as quickly"? As far as I know, jit.matrix and jit.slide aren't aware of 'time' in that sense. They just send out a frame of video when requested (e.g. by a bang), and the rate of requests could vary from moment to moment. So I'm going to assume that by "quickly", they're talking about the number of frames it takes to reach the desired output.
    Here's my theory: say you have a fully red pixel, and you then set that pixel to black. If you were to bang that matrix normally, you'd see that pixel turn to black after one bang. Therefore, if you put that matrix through a slide, with @slide_down 10., I'm assuming it takes 10 bangs/frames for the pixel to fully reach black.
    So I put this theory to the test with a patch, pasted below. It actually takes more like 20 bangs to get the pixel from red to black, and likewise from black to red (with @slide_up 10.).
    It's not a major problem for me - it still creates the desired effect and looks lovely and smooth when hooked up to a metro object. But I would still like to understand exactly how jit.slide calculates it's output, so I can effectively control the speed at which pixels slide up and down.
    Can anyone explain?

    • Aug 17 2012 | 12:56 pm
      Yes, the reference to "speed" can be a bit misleading. But, that's assuming you're having a somewhat constant metro, which in the majority of the cases you do (video/3d)...
      Having used jit.slide often in the past, I got curious with your question and here's my take on it: I've put slide_up/slide_down to "2". From black (0) through red (255), here are the values I've got using jit.cellblock:
      0, 127, 191, 223, 239, 247, 251, 253, 254, 255
      Analyzing the progression, each bang is adding 1/2 of the difference between the last output matrix of jit.slide and the last input matrix... last calculated matix + [ (last input matrix - last calculated matrix) / 2 ]
    • Aug 17 2012 | 1:17 pm
      Ahhh... that makes sense now! Thanks Pedro!
      I had noticed this 'long tail' effect before, but didn't figure out the reason for it.
      So now I'd really like to know how to achieve a similar effect, but with a linear change, rather than a curved one.
      I suppose I could use the [line] object, and then use setcell messages to update each frame one at a time. But I do quite like the way jit.slide takes care of it for you without the need for any messaging.
      Any ideas?
    • Nov 04 2013 | 6:52 pm
      I was wondering if either of you knew how to make jit.slide last longer.. There is a maximum limit with the @slide_down attribute that only allows the motion trail to last a few seconds. I want the motion trail to last indefinitely, or at least 5x as long. Any ideas? or a different object I can use to achieve the same thing?
    • Nov 04 2013 | 7:57 pm
      There's only one obvious solution: you can bang jit.slide less often. Reading your other thread, I think if you want a permanent trail you should have a different approach (maybe a feedback loop with a "screen" or "+" operator or something, sort of an accumulation buffer?).
    • Nov 04 2013 | 11:19 pm
      @walshm - yep, I discovered this recently too.
      From my experiments, it seems the longest that slide can possibly last for is 255 frames (bangs). That's if you start with a value of 255, and slide all the way down to zero, using a @slide_down value of 255. In other words, you're saying to slide "when I tell you to go to zero, instead I want you to go a 255th towards zero". The slide object always rounds down the output, so each frame will always be at least one step lower than the frame before - hence the 255 frame limit.
      So, at 40 frames per second (i.e. metro set to 25), the longest that slide will last is 6.375 seconds. Decrease your frame rate, and slide will last longer.
      As I've been typing this, I've just thought of another possible solution. Most of the time we probably use a jit.matrix with a data type of char (with possible values of zero to 255). But jit.slide also works with matrices of data types long, float32 and float64, which have many more possible values. You could try converting your matrix to one of these data types, before sending it through jit.slide, and then converting it back to char before sending it to the screen.
      I'll have to try that out myself sometime soon...
    • Nov 09 2013 | 7:38 am
      Thanks, I ended up using open GL (tp.slide.jxs-help.maxpat in the help folder) because I was looking for more of a permanent trail, like Pedro said. I can basically "paint" on the screen now using a webcam, but my current problem is that darker things won't show up over lighter things. So, for instance, if you put a white piece of paper over the webcam, no other trails will show up on top of it. I'm not sure if I could change this though unless I used cv.jit centroids or something...