Mathieu Bouchard wrote:
On Mon, 10 May 2010, Martin Peach wrote:
It's easier to see what's going on using the colourbar from hello-world.pd.
But hello-world.pd is unrelated to moving pixels around like [#remap_image] does. [#remap_image] is like a giant [tabread] from outer space whereas hello-world.pd (or [#hello]) is not.
Of course, I just meant that it's easier to see the transformation that [#remap_image] is applying with a simple fixed image.
The [# + (120 160)] doesn't seem to have any effect, while the [# - (120 160)] changes the position of the image.
the [# +] (that goes into [#remap_image]) changes the position in the source image, which leads to a more interesting transformation, in which the borders of the tiles (which are circles) change radius.
So I probably need to use an source image that has texture in both dimensions, as with vertical bars it does nothing obvious.
the [# -] (that [#remap_image] goes into) only changes the position of the image.
basically, it's the same operation, but depending on whether you apply it before or after the inversion, it has a different effect on it. It's like when you plot (1/z)+c versus 1/(z+c).
In this case (using [# put (30000 0)]), it's (1/(z-c))+c, which is sort of a special case because 1/z is sandwiched between a -c step and a +c step, which are exact opposites of each other, and thus you can see it as the 1/z is happening relative to a point other than (0 0). It's just that you choose the position of your simple pôle.
It's like when you do a [# -] [#rotate] [# +] sequence, you are rotating the coordinates around a different point than (0 0).
This concept of applying A then B then "undoing" the A, is very useful and I often put things between [# *] [# /] pairs, [# <<] [# >>] pairs, [# c2p] [# p2c] pairs, with same arguments.
for anything non-commutative, where [a then b] is not the same as [b then a].
I attached my hacked-up version of your patches.
Martin