made with PureData/GridFlow
http://gridflow.ca/gallery/un_sur_z%C3%A8de.jpg
(this is actually one screenshot I took from a live video output.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
fractals! awesome!
Is the patch that created this lying around the woods of public access too? :)
On Sat, May 8, 2010 at 10:46 PM, Mathieu Bouchard matju@artengine.cawrote:
made with PureData/GridFlow
http://gridflow.ca/gallery/un_sur_z%C3%A8de.jpg
(this is actually one screenshot I took from a live video output.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
On Sun, 9 May 2010, Arif Driessen wrote:
fractals! awesome!
Hmmm, I hadn't thought of that before... but there may be a fractal dimension to this figure.
Is the patch that created this lying around the woods of public access too? :)
Here's a version of it, as attachment, without the mirror effect (which would require a few more objects).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, 9 May 2010, Mathieu Bouchard wrote:
On Sun, 9 May 2010, Arif Driessen wrote:
fractals! awesome!
Hmmm, I hadn't thought of that before... but there may be a fractal dimension to this figure.
Is the patch that created this lying around the woods of public access too? :)
Here's a version of it, as attachment, without the mirror effect (which would require a few more objects).
Some more notes about the patch I sent you (on pd-list) :
it doesn't compute 30000/z, it computes 30000(1+i)/z, so this means that it's rotated by 45 degrees compared to what it was supposed to be, and 41,4% smaller. It was supposed to be [# put (30000 0)] instead of [# put 30000], but I took the first thing I made that looked enough like the real thing.
the [# || 1] object is a hack because of a bug I found in [# C./]. It won't be needed in GridFlow 9.10.
the [t a a] [# put (30000 0)] [# C./] will have a shortcut as [# C.inv* (30000 0)] in GridFlow 9.10. This is by analogy with the existing [# /] and [# inv*].
(those changes are already available in the SVN).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Sun, 9 May 2010, Mathieu Bouchard wrote:
On Sun, 9 May 2010, Arif Driessen wrote:
fractals! awesome!
Hmmm, I hadn't thought of that before... but there may be a fractal dimension to this figure.
Is the patch that created this lying around the woods of public access too? :)
Here's a version of it, as attachment, without the mirror effect (which would require a few more objects).
Some more notes about the patch I sent you (on pd-list) :
it doesn't compute 30000/z, it computes 30000(1+i)/z, so this means that it's rotated by 45 degrees compared to what it was supposed to be, and 41,4% smaller. It was supposed to be [# put (30000 0)] instead of [# put 30000], but I took the first thing I made that looked enough like the real thing.
the [# || 1] object is a hack because of a bug I found in [# C./]. It won't be needed in GridFlow 9.10.
the [t a a] [# put (30000 0)] [# C./] will have a shortcut as [# C.inv* (30000 0)] in GridFlow 9.10. This is by analogy with the existing [# /] and [# inv*].
It's easier to see what's going on using the colourbar from hello-world.pd. The [# + (120 160)] doesn't seem to have any effect, while the [# - (120 160)] changes the position of the image.
Martin
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.
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.
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.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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
On Mon, 10 May 2010, Martin Peach wrote:
So I probably need to use an source image that has texture in both dimensions, as with vertical bars it does nothing obvious.
It depends which axis you do the [# -] on...
BTW instead of [pack f f] with [t b a] you can do [#pack] without [t b a] if what you need in the end is a grid of ints. But if you really need the "120 160" init, then there is no shortcut for that.
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].
Yes. I'd like to note that with limited precision, the amount of commutativity can be quite limited : [a then b] minus [b then a] will leave a small trail of residue. Thus I use [# *] [# /] that algebraïcally may look useless, if I forget that I don't work with real numbers or an extension thereof, but with ints, it clearly makes a big difference because of the rounding. (float rounding, however, is usually much more subtle than that, and [# *] [# /] is rarely useful to deal with it.)
I attached my hacked-up version of your patches.
fun :)
I often do such mashups. It's an easy way to produce more interesting results using previous interesting results.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Arif Driessen -
Martin Peach -
Mathieu Bouchard