Hi,
I was going to program something, but wanted to see if someone hasn't done it before. I needed a "weighted average" (probably the name is incorrect, I just made it up), that is: considering an x number of sliders going from 0 to 1, the sum of all sliders would be always 1. In case I drag one slider up or down, the difference in value to the total (1) would be distributed through the other sliders that aren't active. That itself isn't that hard to do, but then harder would be to consider the previous state when the next change happens. So that a slider that is already higher than the others by the next change would "retain" the average countour.
I'll give an example for clarity:
the other sliders. Sliders #1, #3 and #4 would then go down to 0,2 each.
shouldn't happen that #1-3 move to 0,2. instead, the higher countour of #2 should be taken into account. The end result would be something like #4 = 0,4, #2 > 0,2, and #1 & #3 < 0,2.
happen.
only the others move.
Is there any external/patch for this, or any statistic formula / website I should look at for this?
Thanks,
João
Hey Joao,
Connect all the sliders to a [+ ] object and then divide the single output of every slider by that sum (output of [+ ]). You'd probably need a [trigger f f] directly under each slider. Is that an answer to what you asked for? If it's an additive synth you're builiding you don't want to clip I guess so.
Funs
attached is a possible solution the logic is: add the values of 4 sliders divide 1 by that sum multiply all slider values by that number gr, Tim
2010/6/16 Funs Seelen funsseelen@gmail.com
Hey Joao,
Connect all the sliders to a [+ ] object and then divide the single output of every slider by that sum (output of [+ ]). You'd probably need a [trigger f f] directly under each slider. Is that an answer to what you asked for? If it's an additive synth you're builiding you don't want to clip I guess so.
Funs _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
sorry, the attachment was 0kb, my harddisk was full... see this attachment gr, Tim
2010/6/16 tim vets timvets@gmail.com
attached is a possible solution the logic is: add the values of 4 sliders divide 1 by that sum multiply all slider values by that number gr, Tim
2010/6/16 Funs Seelen funsseelen@gmail.com
Hey Joao,
Connect all the sliders to a [+ ] object and then divide the single output of every slider by that sum (output of [+ ]). You'd probably need a [trigger f f] directly under each slider. Is that an answer to what you asked for? If it's an additive synth you're builiding you don't want to clip I guess so.
Funs _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I just opened it and slided around. thanks, that seems to be it. I guess
it's easier to program if the control sliders are separated from the
"result" ones. the top limit of the control sliders can be higher (for
more radical results), but I can improve that.
thanks, that saved me a couple of hours and brain cells.
João
sorry, the attachment was 0kb, my harddisk was full... see this attachment gr, Tim
2010/6/16 tim vets timvets@gmail.com
attached is a possible solution the logic is: add the values of 4 sliders divide 1 by that sum multiply all slider values by that number gr, Tim
2010/6/16 Funs Seelen funsseelen@gmail.com
Hey Joao,
Connect all the sliders to a [+ ] object and then divide the single
output of every slider by that sum (output of [+ ]). You'd probably need a
[trigger f f] directly under each slider. Is that an answer to what you asked for? If it's an additive synth
you're builiding you don't want to clip I guess so.Funs _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ah right, an unnecessary step ofcourse. but I do find it easier to understand that way, and you can adapt that '1' to the desired sum directly...
Tim
2010/6/16 Funs Seelen funsseelen@gmail.com
x / y or x * (1 / y) What's the difference? Funs
On Wed, 16 Jun 2010, Funs Seelen wrote:
x / y or x * (1 / y) What's the difference? Funs
There is a slight difference. It should stay well below a millionth of the result (0,0001 %) but I haven't made a theoretical measurement so I can't guarantee it. It's due to rounding numbers. If y is a power of two (2, 4, 8, 16, ...) then there is no difference at all. For other values of y, the amount of error depends on x in a funny pattern.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 16 Jun 2010, João Pais wrote:
I was going to program something, but wanted to see if someone hasn't done it before. I needed a "weighted average" (probably the name is incorrect, I just made it up), that is: considering an x number of sliders going from 0 to 1, the sum of all sliders would be always 1.
The standard definition of the thing called "weighted average" is quite related to that. you compute the average of four numbers x1,x2,x3,x4 using four numbers a1,a2,a3,a4 by doing a1*x1 + a2*x2 + a3*x3 + a4*x4. All the a variables are nonnegative and they add up to one. In another variation, there's no requirement that they add up to one, but they have to add up to something else than zero and you divide by a1+a2+a3+a4 at the end to normalise the result (as if they added up to one).
Weighted average is also called "convex sum", because you can make all possible convex filled polygons with it (and nothing else) if you do it in two dimensions.
In case I drag one slider up or down, the difference in value to the total (1) would be distributed through the other sliders that aren't active.
That requires quite a lot of objects if you don't use any externals.
I'd suggest instead to just have four normal sliders ranging from 0 to 1 and normalise them by dividing by a1+a2+a3+a4. The only time it won't work is when all sliders are at zero. (this is what Tim Vets made for you).
That itself isn't that hard to do, but then harder would be to consider the previous state when the next change happens. So that a slider that is already higher than the others by the next change would "retain" the average countour.
I don't understand this or perhaps it's not an extra feature and just implied by equally distributing the excess and the lack.
Is there any external/patch for this, or any statistic formula / website I should look at for this?
I think that the difficulty is more in plugging the objects together.
If I had to do it myself, I'd do it using the [#many] abstraction, and I'd expect to use [#outer != (0 1 2 3)], [#fold +], [# *], [# -], [# /], [norecurse], and some more. With that, it'd take a lot fewer objects, and would then be easy to adapt to five, six, eight, any number of sliders, whereas an ordinary solution would take obscene numbers of modifications and of total objects. But even with GridFlow, it's not such an easy problem (to make it exactly like you want it).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, Jun 16, 2010 at 01:25:09PM +0200, João Pais wrote:
I was going to program something, but wanted to see if someone hasn't done it before. I needed a "weighted average" (probably the name is incorrect, I just made it up), that is: considering an x number of sliders going from 0 to 1, the sum of all sliders would be always 1.
[list-equalize] in the [list]-abs does this for lists. I called it "equalize" so it's different from [list-normalize] which does the same as array-normalization (scale all so the peak is 1)
Frank