making a matrix scroll the *other* direction

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

    • Jan 13 2010 | 4:53 am
      You wanna try posting up a small patch that shows what you've got so far?
    • Jan 13 2010 | 5:29 am
      Andrew, how do I get an icon on the forums?!
    • Jan 13 2010 | 6:12 pm
      Here you go:
    • Jan 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:
    • Jan 15 2010 | 12:25 am
      I'm a little confused. Doesn't this work exactly the same as the patch I posted?
    • Jan 15 2010 | 12:33 am
      whoops, posted wrong patch. i've updated the previous post.
    • Jan 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.
    • Jan 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...
    • Jan 25 2010 | 4:10 pm
      Any more ideas?
    • Jan 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.
    • Jan 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.
    • Jun 22 2013 | 11: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 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 2 3
      So the solution is to use an extra data copy, a second matrix.
    • Jun 23 2013 | 5:02 am
      You could use the 'offset_x' attribute of jit.rota.
    • Jun 23 2013 | 9: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.
    • Sep 24 2015 | 3:31 am
      Hey everyone, does anyone know how to make @andrew benson's Jit.convolve method wrap? Thanks
    • Sep 24 2015 | 7:43 am
      sorry, let me expand a bit. I'm having trouble replacing the jit.noise with a regular matrix that i can load an image into. I can load an image into the jit.matrix "shift" but then the image doesn't wrap when it scrolls through. Any help would be appreciated, thanks.