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.