On Thu, 17 Jun 2010, João Pais wrote:

yes, but since my math skills aren't much better than basic, all those equations and polynomials mean nothing to me. unless I get a clear equation (like the cubic one I used, which I found in another site), I can't go any further. if anyone wants to translate those funny drawings for me into something comprehensible, I'll put it in the patch.

Then this means I'd have to give you one formula per order, or what ?

The general formula goes like this : time goes from 0 to 1. to figure out the position for a time we call "t", you do this for each point numbered "i", you multiply the point by t, i times, and you multiply the point by (1-t), n-i times. It gives a pattern like :

[expr pow(1-$f1,3)*pow($f1,0)*$f2 + pow(1-$f1,2)*pow($f1,1)*$f3 + pow(1-$f1,1)*pow($f1,2)*$f4 + pow(1-$f1,0)*pow($f1,3)*$f5]

I put the pow(,1) and pow(,0) in the formula just to make the pattern obvious... pow($f1,1) = $f1 and pow($f1,0) = 1, so, they'd be skipped in a "real" formula.

So, to adapt to 5 points, you'd add a $f6, the exponents in the first column would be 4,3,2,1,0, and in the second column they'd be 0,1,2,3,4. You can see that you can add any number of points like that.

It's more difficult, though, to make a patch that supports all possible orders at once. One way you can do it is with a [until] or [list split] or [list-drip], to compute the formula for one point at a time, and a [f] [+] combination to add the results together, for example. All this because you can't make a single [expr] that supports any number of points.

my purpose of doing this is basically to "modulate" a [line] (0-1), that is, with one direction. I never worked with higher than cubic curves (coreldraw etc are cubic), but since the purpose is to have a line that follows only one direction, would it become that unpredictable?

CorelDraw curves do the same thing in two dimensions by doing the same formula twice, once for the x, once for the y. Everything funny that you can do with those curves in 2 dimensions has a reason that comes from the 1-dimensional case. If you setup your points to bounce back and forth in a big-order Bézier, you will get an overly jumpy curve. Here's an extreme example :

http://demonstrations.wolfram.com/RungesPhenomenon/HTMLImages/index.en/popup...

this example is a Lagrange curve instead of a Bézier curve, but the jumpiness is a problem with all methods (some more sensitive than others).

...

So, usually, when they have more than four dots, people chain together pieces made from three or four dots each.

I know. that's another thing I have to look at in the future, but don't have a) the time and concentration b) the necessity for it. although it would be better, because then the patch would be "complete".

If I wanted a [vline] that did Bézier, I'd expect it to be chaining together pieces of Bézier that use three or four points at a time. Sort of like the difference between [tabread] and [tabread4], but with a better formula than [tabread4].

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

thanks, I'll try to put this in when I can. meanwhile dtmod wrote me
saying that he's doing a real external for this, so that would be a better
solution. anyway since I started, I'll try to finish my work.

...

[expr pow(1-$f1,3)*pow($f1,0)*$f2 + pow(1-$f1,2)*pow($f1,1)*$f3 + pow(1-$f1,1)*pow($f1,2)*$f4 + pow(1-$f1,0)*pow($f1,3)*$f5]

doh, I forgot some multipliers.

[expr 1*pow(1-$f1,3)*pow($f1,0)*$f2 + 3*pow(1-$f1,2)*pow($f1,1)*$f3 + 3*pow(1-$f1,1)*pow($f1,2)*$f4 + 1*pow(1-$f1,0)*pow($f1,3)*$f5]

when you vary the order, the 1 3 3 1 sequence goes like this :

1 1 1 1 2 1 1 3 3 1 1 4 6 4 1 1 5 10 10 5 1 1 6 15 20 15 6 1

notice how the numbers for each order are made from the numbers for the previous order : each number is the one above plus the one to the left of the one above.

you also get that same pattern of numbers doing various things such as
the theory of coin-flipping, approximations of Gaussian blur, or if you
expand pow(x+1,n), e.g. :

pow(x+1,4) is the same as : 1*pow(x,0) + 4*pow(x,1) + 6*pow(x,2) + 4*pow(x,3) + 1*pow(x,4)

Note that http://en.wikipedia.org/wiki/Pascal_triangle has some cool drawings and animations about it. (I especially like the fact that a fractal appears in that number pattern if you make many rows of it)

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

...

wrote me saying that he's doing a real external for this, so that would be a better solution.

Why is an external a better solution ?

isn't a hard coded external always more efficient than an abstraction, specially if tcl/tk and gop are involved? I thought so.

Anyway. I was inspired to make a bézier patch. It's an integer solution, so, for 17 points I run t from 0 to 16 instead of to 1, then I divide by pow(16,3) at the end to compensate. I could redo it in floats with almost the same number of boxes though.

Here's the screenshot of the whole patch :

http://gridflow.ca/gallery/bezier.png

It takes only 9 (nine) objects to compute it. For large numbers of
points, I can add a cache using two more boxes. Float requires two extra boxes (and editing some more). Using a different order doesn't require any repatching, just edit three or four boxes to change some numbers (I'm not counting the fact that you have to recreate the multi-numberbox at the right to have more rows). When I count the objects I'm not counting the multi-numberbox nor any of the objects on the left. The wire that goes up is carrying the polygons ready to be rendered.

I have my patch in the other computer, can't send it now. my patch shows only a gop with the line (array) and 4 control points, which can be moved around with the mouse. it's also possible to dump the present coordinates
of the points, and to feed others into the array. so it can be used
graphically or with parameters. there are also a couple other details, and other things I want to do, but
won't have the time for now.

if I remember, I can send the current version tomorrow.

João

...

isn't a hard coded external always more efficient than an abstraction,

What's the speed that you need ? What's the speed that you want ?

I never measured it. what's the speed of pd? I guess as less speed as
necessary, so that it doesn't bother other processes. also, in order to
make it a sucessful abstraction, I have to put in extra code just to make
sure that the data-s are created properly. although it's stable, it's
always a drag.

...

specially if tcl/tk and gop are involved? I thought so.

After it's computed, you still has to render the result.

Chances are that you'd still render it with Tcl/Tk and GOP.

GOP itself does not introduce a noticeable slowdown in pd-vanilla nor pd-extended nor pd-devel.

that might depend. some days ago I had a patch with 3 lines feeding into
number boxes, and that alone made the cpu go up at least 10% (maybe
more?). In my laptop trio I used a gop data-s abstraction to display the
panning of the players, but replaced it with a gem patch. only that small
module used ~ 20% cpu. in the end it's a waste, if you're trying to do
that + 100 voice samples at the same time.

the example from dmtod#* seemed to be a full external, that might save
some computation time. he also had the dashed lines to the control points,
it's a small plus. (I could also do them with data-s, but can't be
bothered).

...

I have my patch in the other computer, can't send it now. my patch shows only a gop with the line (array) and 4 control points, which can be moved around with the mouse.

I know, you sent it and I've seen it. I decided to concentrate on the formula, so I did it with numberboxes instead. It's possible to use the
GF computation together with a DS rendering.

ah, I forgot. the latest version can be fed the precise coordinates for
each point separately, just like yours - I just scaled everything from 0
to 1, since the patch is supposed to be a 0-1 transfer function.