[ANSWERED] Smoother and Gate (Output Still Green When Value Says Zero?)

Michel

It's also not clear for me what you want to achieve. If I look at your patch I don't see any input for midi. Is it just an extract of your patch? Can you explain a bit more what the final result should be?

Best Michel

Bennnid

hi and thanks for your reply,

I acknowledge using a button to reset a parameter assigned to a continuous controller is not really "functional", but that's how I need it,
As the patch is messy I just extracted to bug to highlight the behavior pb of smoother.
in split view 2 buttons:
-"rotary to 0" emulates a midi continuous controller going down to 0
-Reset to 100" emulated a push button that would reset the value to 100,

when you push rotary to 0 you 'll see the patch cord outlet of smoother stays green and continues sending output although value smoothing is finished,

thanks

Michel

@bennnid

Well it is actually the smoother actor sending continuously based on the frequency set. No matter if the input value is changing or not (how should it know in advance if the value will change). If you set the frequency to 1Hz you will see that the cord will blink red/green every second, smoothing the previous and the current value, even though it did not change. If the gate gets closed the pushed value will not go through.

Best Michel

Bennnid

@michel

sorry I should misunderstand, I thought this was the forceout function role to continuously send output,
and the smoother can definitely be not outputting value when no change comes in isn 't it? ,
in this new version of the patch you will see that non 0 input in the smoother ( here 10) will make the output pause after 6 sec, as the timer shows,

thanks for your patience helping me, I'm going a bit puzzled...smooth push bug2.izz

Michel

@bennnid

OK, I can imagine what happens what may be a bug or maybe not. If you set the value to 0 the smoother will smooth the value in so small steps (for example 0.000001 increments or even smaller) that the value can not be shown on the output because it can only show 4 numbers after the floating point, you then see a zero even though its not yet.

So a workaround I just have tried is, to type the value 0.0001, that's small enough to not see the live footage anymore.

@mark, is this behaviour a bug?

Best Michel

Bennnid

Thanks ,

indeed it's wired cos even with 0,0001 it take 5,6 sec after the visual number is reached to let the patch cord go red and stop outputting flood...
with 0 as a target it sends data for a few minutes and stops when you select and unselect the actor, seems really a bug behavior to me...

thanks

mark

@michel said:

@mark, is this behaviour a bug?

No it is not a bug. It is simply an artifact of the algorithm, and perhaps is also more noticeable in Isadora 3 because it users floating point numbers with twice the resolution of Isadora 2. (64 bit instead of 32 bit.)

The 'smoother' has two values -- the target value (in this example '0') and the current value. If the difference between those two values are high, then the amount added or subtracted to reach the target will be greater and it will "move faster." But if the value is very small, then the amount added or subtracted will be very small.

Consider the value 0.00001. I know this would be represented as 0 because Isadora only shows four decimal points, but as we've discussed it's not actually zero inside of Isadora's "brain."

The algorithm would progress sort of like this:

Current Value = 0.00001, Target = 0, Difference = 0.00001. Subtract half of that and the new value is 0.000005.
Current Value = 0.000005, Target = 0, Difference = 0.000005. Subtract half of that and the new value is 0.0000025.
Current Value = 0.0000025, Target = 0, Difference = 0.0000025. Subtract half of that and the new value I s0.00000125.0.
Current Value = 0.00000125, Target = 0, Difference = 0.00000125. Subtract half of that and the new value is 0.000000625.

etc., etc.

Can you see that the number is getting smaller and smaller, and thus the amount subtracted is less and less? Because of this, it might take a very long time to get all the way to zero. This is the nature of the smoothing algorithm.

(It's a bit like cutting a piece of paper in half again and again. In theory, you'll actually there always be more paper to cut in half until three is nothing but single atom.)

Perhaps you can use a Comparator to solve this problem as follows:

If the value is greater than 0.0001 then the value is multiplied by '1' and is unchanged. If the value is less than or equal to 0.0001 (or whatever number you choose as the bottom limit) the value will be multiplied by 0.0 and thus it will be truly and exactly zero.

Could that solve your problem?

Best Wishes,
Mark

Bennnid

hi Mark thanks a lot for making clear the under-text we don't see;-)
Comparator is definitely the better way to solve this !
But I'm also wondering when mathematical coherence becomes more important than "usability" ... ( maybe because French language is full of exceptions ;)

best regards !

mark

@bennnid said:

But I'm also wondering when mathematical coherence becomes more important than "usability"

Well, you're the first person to complain... so maybe it simply comes down to the fact it is not the right solution for the problem you are trying to address.

This plugin uses a simple and standard smoothing function that is designed to smooth continuous streams of data from a sensory input. For that purpose, it works extremely well and you want the behavior you criticize.

Here's the actual code:

// new_input is the value that just arrived at the actor's 'value in' input
// last_output_value is the value last sent to the actor's 'value out' output
// smoothing_constant is the actor's 'smoothing' input
float new_value = (new_input - last_output_value) * smoothing_constant + last_output_value;
-> send new_value to 'value out'
last_output_value = new_value;

What you are looking for I think is something that does not take the last value into account, but moves at a continuous rate towards the target value. This is something I have also desired, so I'm building a plugin right now. I should be able to get it out today.

Best Wishes,
Mark

mark

@bennnid said:

But I'm also wondering when mathematical coherence becomes more important than "usability"

Here's a newly minted actor: Seek Target Value.

Instead of a smoothing function, this actor simply seeks whatever target value you set as an input at a constant rate you specify.

For example, if you:

1) Set the the 'target value' set to 0.0
2) Set the 'change/sec' to 2.0
3) Then set the 'target value' to 6.0

then the actor will smoothly move towards 6, taking a total of three seconds because the change per second is 2.0 (6 / 2 = 3.)

I think this might suit your needs better than the smoothing actor. Try it and report back.

seek-target-value-v0.9.0.zip

Best Wishes,
Mark

Kathmandale

Taking a moment to be philosophical, Zero is a fairly modern concept as far as mathematics is concerned, especially in 'Western' cultures. For a long time we didn't need zero because you don't go out to buy zero loafs or need to count your zero sheep. In more recent centuries Zero was banned as an idea in the west and considered heretical because of what it represented; if God is infinite then Zero represents the opposite of that, the void, and in the void not even God can exist. Worse, mathematically Zero shares many properties with infinity. There's a perfect example above: using the smoother actor (and allowing for infinite floating points) you can never reach zero by dividing other numbers, you can only approach Zero, just as you can only approach infinity.

The Greek philosopher Zeno had a perfect example of the Smoother Actor in motion in his Achilles & The Tortoise Paradox. In modern maths we have Zero so can impose a limit on the terms, the ancient Greeks didn't. They just saw a sequence of numbers get infinitely smaller for an infinite amount of time.

There's an amazing book by Charles Seife, Zero: The Biography of a Dangerous Idea. It's perfect lockdown reading and I'd recommend it to anyone and everyone.

CitizenJoe

@mark said:

Here's a newly minted actor: Seek Target Value.

Mark, you constantly amaze me.

Cheers,

Hugh

Bennnid

@mark thanks a lot for your patience teaching me those subtle maths,
( all apologies if my newbie s remark seems nonsense, I might not understand functions deeply as I m more empirically finding solutions,
I come from different live composing languages (conduction and soundpainting) when I felt stuck in my own rules, and had to adapt in real time contextually, shaping the tool to shape reality...)

1st let me clarify a bit the context:
Using a midi fader (0-127) to zoomer actor (0-1000) , I have a "stairs effect" (not fluid), so I need to turn it more linear.
Smoother actor works perfectly fine for this although the "going to zero" process creates this endless "Tortoise paradox" @Kathmandale (thanks so much for this picture and reading advice;-), but comparator will solve this as you mentioned.
Unfortunately Seek target value actor doesn't allow to follow the speed of the gesture on the fader, and it gives every movement the same speed which is not helpful in my case.

Thanks !

mark

@citizenjoe said:

Mark, you constantly amaze me.

Well, this is an actor I've wanted for a while. @Bennnid 's post gave me the reason to do it.

Best Wishes,
Mark

DusX

Not the same, but another option within the same realm.

Value Decay User Actor

Bennnid

Hi here's a way to solve my problems, if you have any comment please let me know !
I'm a bit doubtful regarding the priority in the chain.. (between gate and trigger value at the end)

Best regardsSMOOTHERGATED.izz

Bennnid

@dusx thanks I've opened it but lots of infos there, I need to take more time to understand it more deeply;-)