jit.slide – a little confused about the finer points…
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.).
----------begin_max5_patcher---------- 576.3ocyVEsbhBCE8Y3qHSd10IIRPsO086XmNNAHqFGHvRBp61o+6KbCTq6R qTGsx3nwbuWhmyI2ShO66gixOHMXzCnef77d12yCB0DvqctGNSbHNUXfxvZ4 97ns3ItTV4AKD9WYRaYNhQPOJhspcRDsqFUBTQ8S8MJqK3Oy0VsHSBo9doRj 1kQWkozoRK7ywNFLux1Ek9lEwn9CrHT1TRa3BgMdiRudUoL153FOnNKhxov. CFXjoDzSsOia0s+tP5d.bjPuFidpI6K99MeLYfJzVkcZwdkNIeeORv7d4IsW dxdeBwBHMbHvMPCImmQ3I0uuHF8N64MD0jpRjnGggU0LVinjocyqJZl0iHD9 IaC9X4Y3sALBzGLaIGjK1ryqZ0jbUlvVpNb45WlzXDqk+m.Zj1XYZJhf1IRQ LNu9a0u5Qv32IeCiGdhwYNLr3CaytAlF1U0zvlu39ZZb8SnpBM3XBPwaDknE 8cf480nvlwca+AiMiRqYoGIK3dYUZOJl4tpIfdqrJQUVattGlu7SzRPO6deq mmQtk2UJr1xJUeM9jqRm+EuMNyc2.kOjyHdMUCcbMrudeH9ppJz6rpDbETkp h2pIPU3Tk9e+an.JZhepPYxqJi69M5zDzQbjHMVkVXU0VjiEEdRMaTIIRHcG kSTFQTpDTZRu6XCFNjwEbFUnIb.nY9WFZVN.zP+xPCeTglfQEZFRWL6BQi6. HQQwNYoocIAfTel71b3fqvIvTk1MEVQbobmpqdteyp8h+eQaAbXu -----------end_max5_patcher-----------
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?
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 ]
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.
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?
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?).
@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…
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…
----------begin_max5_patcher---------- 1104.3oc2Y0sahiCF8Z3oHBsWxF4ehSByUy7brZDxPbotJjjwwzxtil2809y jY.VEG2NIzsnVEvNlv46v46O6uOe1hM0GEsKh9TzeEMa12mOaFLkchYmFOaw d9wsk7VXYKpDuTu4oEKc2RKNpgoKq4Ea3U65tQCWu8QY0t0JwVs64SSPwYrk QrzXzxnTj8JwbM5qm9LxB3QYd7+Il08fdntRWw2Kfa8EkjW1cmpC6kUkBMfK 7YKuU9Ovxw33UzjLJ9Wef5C5q+Dtoz+civAyEfYD8U6c+w741KKCja1KZa46 D+GxggPAvK4IVFgRhMuGm2Cufdk7BY73k2Fmzid4IoNdWYbaIeSzCbOrCNEj KDRNnZV4U0jL4rCoO1wXPq2Ut1ZfGTFIvakudnr17M5StXTHFN.Sn1WX9ciH CSHMbkYdsPsVTw2TBq.MNtX8RVFijqsbz36q0VJKDqKpeoJ5OvAPiIf7JmAC 5yqi9QyqaPUDwE+MLUD9tUE4I5zKxJiJZffSqbjHD4NKwGIRVM4YzHdynsbj if2njUZeJrrSAtyfzZTujS9jSNnQO20yl.M0Mk7JgQjD841s7RQDNlRolql+ CHolqTHBJyK4j89obrY01y0J4wQW+bYE.Qe9Aog9zMwP.73mN1F.+g.UElk6 k+R+3WUPeY61IzPj2RYqOeQbNFHJW4St.U8krivtSJwrQIZDUEQ.AEPpvTPE k6sBSRx6WeISQcRGZ7WkTG23pRJC4sJorOZBm93lsk0sBerhqUMm2DM2Goje uvI0FeIeTRxY8mQy7QIY2Qsv9MSNLkIAFkfLT.Z3TVXjyGBk5KLS58bFekIn rPA47qU5GqiHCWg8IVi5sDa1cVE15nMl+DJt2fQNFJEpDJk4iel9bWzg3mtW cF0zzZqqnZrqsCuYyo+d80ZnJ4dCTrSEy9v1r62L1mJDuvDvIj4MxE48K39a mXz061UNrOF9mso4YuRdyaHRfVoso6KLR.EKJkUWuO9fcXm+RKus9fZa2Sqa Oki9kwTHZ0xJtVVWc9hHWrnGkEEhpKcFJZpMf6DHnLWSFHxY7Tgr0REE82Od vXlEBlQCf4wCOYA.mzWGCRXY1SBXkamIyXcCl.1LeBP+JJ.Xx4neZzBlzZQ3 wE8LLf27yAe9j.9z.ndR5MSGa2p2g8qxtc3ID54lgFZfnAeSPCI.zjby3lj. PC6lhFxuIZtJlPVBDF.1HMRd26mhbagjLgb69kkvFiXTWwl3UH3btuHAAdhx PPRl.KfjtxcR8qN2BrilBKHMfjbj7WYMZXPRSHttFyY+bzTnpCIbEld6xrPG CurqYzDnvgtim3jBwNZpzDCxn2t3D3f7xx9eFdRGHe80wsb94DFwcplmNGuK F41rJJFewHmuFBEfVv0RGuo4Ygp8DdAyzz15S0J6vzkyc6.gaHzt3Bk3YY25 SfY3JSqrZSer1Sex1i5w7zEyseO+X9+xk.hK7 -----------end_max5_patcher-----------