Forums > Jitter

making a matrix scroll the *other* direction

January 13, 2010 | 12:50 am

I recently learned the trick where one can make a jitter matrix seem to scroll to the right by offsetting the source and destination dimensions.

I’m wondering why this isn’t reversible, in other words why making the dstdim range one value higher than the srcdim range seems to erase the matrix rather than making it scroll to the left.

Is there a way to make a jitter matrix scroll in both directions?


January 13, 2010 | 4:53 am

You wanna try posting up a small patch that shows what you’ve got so far?

AB


January 13, 2010 | 5:29 am

Andrew, how do I get an icon on the forums?!


January 13, 2010 | 6:12 pm

Here you go:

– Pasted Max Patch, click to expand. –

January 15, 2010 | 12:16 am

huh, interesting patch! Might be some different approaches that would work better, depending on your end goal, but with your current configuration, you can just flip ‘er around:

– Pasted Max Patch, click to expand. –

January 15, 2010 | 12:25 am

I’m a little confused. Doesn’t this work exactly the same as the patch I posted?


January 15, 2010 | 12:33 am

whoops, posted wrong patch. i’ve updated the previous post.

-Ben


January 15, 2010 | 5:14 am

Interesting, I never thought of just flipping it around like that. This works for what I need, but I still want to know why my way didn’t. I don’t understand it.


January 15, 2010 | 11:49 pm

On second thought, I’m not sure this solution would work for my patch as I wanted to be able to toggle between scrolling both directions so I can center the data in the pwindow. Back to the beginning…


January 25, 2010 | 4:10 pm

Any more ideas?


January 25, 2010 | 10:19 pm

jit.convolve can also be used for shift-register style scrolling. Just change which pixel of the kernel is set to 1. to switch scrolling direction.

– Pasted Max Patch, click to expand. –

January 26, 2010 | 12:35 am

Thanks Andrew! This should do everything I need. And good guess as to its use: a shift register.

I only barely understand how this works and still don’t understand why my original example doesn’t, but perhaps I should let it go unless anyone wants to offer an explanation.


June 22, 2013 | 4:54 pm

(Sorry, a little late to the party…)

I think I see what was wrong with original coding.
The matrix was being copied onto itself. That is an okay thing to do, unless you are overwriting data in the matrix that has not been copied yet.

So apparently Max first copies location 1 into location 0…
0 <- 1
1 <- 2
etc
and that works for the shift left.

But for the shift right, the original data in location 1 is destroyed by the copy, for it now contains the data from 0, so that data is replicated throughout the matrix.
1 <- 0
2 <- 1 ; wrong
3 <- 2

So the solution is to use an extra data copy, a second matrix.

– Pasted Max Patch, click to expand. –

June 22, 2013 | 10:02 pm

You could use the ‘offset_x’ attribute of jit.rota.
<code>

– Pasted Max Patch, click to expand. –

</code>


June 23, 2013 | 2:37 pm

Nice. That is definitely the most elegant way to do it.

I think I looked briefly at jit.rota, but got scared away by the apparent complexity of the underlying operations. (Cosines and such for each x,y new location, according to the formula on the help page.) I have an underlying aversion, maybe a phobia, about code that is not at least reasonably efficient. Of course, particularly on modern machines, I’m being silly.


Viewing 15 posts - 1 through 15 (of 15 total)