Fader go back to previous value when moved AFTER being successfully set to a new value !

Fixrobert's icon

Hi list !
For four days now I've been banging my head against this simple patch and still cannot figure out how my fader go back to previous value when moved AFTER been successfully set to a new value when clicked.
Any help much appreciated

Max Patch
Copy patch and select New From Clipboard in Max.


Source Audio's icon

The problem is timing and routing.
It would be easier to debug if things were
connected instead of sending arround.
But to simplify, You must decide on few simple things.
1- should fader be blocked when ramp is running,
or does it stop the ramp and then send values out.
2- modifiers - mousestate - hover combo must be
rearanged.
You have to use hover over fader & modifier
to update fader to 1st or 2nd breakpoint value, without sending it out.
and before mouse clicks on fader.
I would use something like grab and set $1 ...

Fixrobert's icon

Hi, thank you so much to answer me.

1- Got the same issue when blocking the ramp with the rooter (just adding a message (0 1 0) triggered by hover), but, in fact it is blocked with the change...
2- Nothing comes out function when moving the fader, it just changes breakpoint inside the function.
And nothing comes through the patchcord between router and fader...

The question is : where does the message come from to change the fader value once it have been allready changed ?

Fixrobert's icon

Ok, here the same patch with no "sending arround" as you say (only patchcord)
I've deleted the pathcord between rooter and fader as it is only useful when banging the function (producing the ramp)
The only message that the fader receives is a set message, triggered by a click in the fader.
So, again, who can the fader go back to it's previous value when moving it ?
Still a mystery for me.

Max Patch
Copy patch and select New From Clipboard in Max.

Source Audio's icon

from zl lookup, try to disconnect it.
Mistake is to click the fader in order to update it's value
to last stored value.That is the conflict.

Fixrobert's icon

No, zl lookup trigers a set message that gives a new value to the fader when it is clicked. And that's all.
Still the fader goes back to its previous value when moving it...

Source Audio's icon

And I don't see why this all has to be so complicated,
when using only 2 points, it is just a simple ramp.

Source Audio's icon

Max Patch
Copy patch and select New From Clipboard in Max.

Source Audio's icon

Here is something that I would do :

Max Patch
Copy patch and select New From Clipboard in Max.

Fixrobert's icon

Ok, it works barely as I wanted. Thank you.
Still don't have any explanation about my bug, Grrrrr

Source Audio's icon

I did put fader in absolute mode.
Explanation for the bug You had is simple,
fader did not receive correct values before it got clicked.
The reason my patch works is that whenever
one hovers over and out of fader, values get
dumped, and also on each modifier status change.
So fader reflects current value before getting clicked.

Fixrobert's icon

Yes !
Sorry for the absolute/relative misunderstanding, I didn't check with enough care.
Thank you so much for your help.