fader with input and output

[sm_jamieson]

I connected a fader with input and output to my script, so the script could either read the values via the callback, or set the position of the fader if required. However what happens is the value last sent to the fader is maintained by the fader so you cannot move its position. If you send nothing to the fader, it gets stuck on zero. What you cannot do is say "move the fader to this value". I have made sure there is not a message loop causing the effect. It is the sticky nature of the fader input that seems to be the issue.

Is there a solution to this ?

Thanks,
Simon.

[sephult]

Events Control -> Pass Only if Has Changed.

So this will let you control the fader and ignore the input. If your script or input changes then the fader will update.
Similar to like a bi-directional fader.

-S

[sm_jamieson]

Events Control -> Pass Only if Has Changed.

So this will let you control the fader and ignore the input. If your script or input changes then the fader will update.
Similar to like a bi-directional fader.

-S

Thanks, that was *almost* what I needed, the only issue being if you want to set the fader to the same value you did last time, the Pass If Change does not trigger. I thought about connecting up a Pass Event Flow but that would need an extra out parameter to set (and then to unset a bloc later to create the trigger pulse), which I could not be bothered with. So in the end I just make sure that if the value is the same as last time, I send out a dummy value one different to what I want, followed by the real value a bloc later (actually 2 blocs later just to be safe). That works for my particular script but its a bit of a bodge, so I might change it to use a Pass Event Flow module.

Update: my fader is integers between 0 and 127. If I pass the dummy value as 0.1 above the value I want followed by the actual value two blocs later, this triggers the Pass If Change module but the fader rounds it to an integer so it is never set to an incorrect value, even for 2 blocs

Simon..

[woodslanding]

Good thinking!

There are times when usine's insistence on treating everything as a signal gets frustrating, and this is a good example. There are times when we really need actual events! I like reaktor's approach of having signal lines AND event lines, with methods to convert between. Pass if changed -sort of- converts, but it breaks down in this case....

I've run into this problem so often, and it's always been difficult to get around.

Did you do this with a script or with modules? Can you post your solution?

thanks!!

[23fx23]

if i well remember you can set the output from your script to update the fader, then set the output length to 0 and it will be equivalent to external pass if change. (but then remeber to set it back to 1 when setting values)

[sm_jamieson]

if i well remember you can set the output from your script to update the fader, then set the output length to 0 and it will be equivalent to external pass if change. (but then remeber to set it back to 1 when setting values)

OK I will try that. A bit like when you set midi output length to zero to prevent repeated midi messages on the next processing cycle. The midi signal is an array and you are setting the array length to zero but I'm not sure if that makes a difference.
Simon.

[sm_jamieson]

I also saw the older thread about setting length to zero to achieve this. Just to say, it only works if you have separate inputs and outputs, i.e. using SetIsOutput() etc. If you use an input / output parameter, you end up setting the input length to zero too !
So in callback I set the length to 1, then set the output value, then set a reset flag for the next cycle.
It appears that for each cycle, callback is called before Process, so I also set a flag telling Process that a callback has occurred, so not to set the input back to 1 until the next cycle. If callback is called and the reset flag is set then it has to act rather than Process of course, since you may want to send another value in the callback routine.
The other thing is that setting length to zero in the init() routine does not work, so I set the reset flag in there instead.
Its a pain there is not a SetOutputLength() and SetInputLength() to avoid having to use 2 parameters, but there you go !
Simon.

[23fx23]

mm yes when i was using this i had separate in/outs indeed, that make sense it will set booth to zero otherwise..isn't it better to have booth separate? just curious why do you use a in/out tparam?

[sm_jamieson]

mm yes when i was using this i had separate in/outs indeed, that make sense it will set booth to zero otherwise..isn't it better to have booth separate? just curious why do you use a in/out tparam?

The only reason I was using an in/out was to simplify the script. Using this had worked fine until this issue.
Simon.

[shawnb]

I had the SAME problem. I have a listbox that feeds a fader (for rapid access to certain fixed values), plus the fader can be used (for fractional values). Pass Only if Has Changed had quirky behavior as you noted above, sometimes the value doesn't change but you need it triggered anyway. After much experimentation, I now do the following:

Listbox output (arrlist) feeds a Pass module IN input
Listbox output (mousedown) feeds a Data Delay (4 ms delay) which in turn feeds a Pass module's PASS input

The Pass module feeds the Fader.

This guarantees that:
(a) the value is passed every time the control is touched (mousedown), and
(b) the delay ensures that the value has been updated before it is acted upon; this is due to the fact that you don't know execution order in HH, the fader logic might be executing before the listbox object or vice-versa, causing the fader to work with stale data within that execution cycle. Without the delay (or with a delay < 4ms), you get the prior value every time; with the delay, you get the updated value every time...

Below is a link to a sample patch showing the behavior of the different techniques discussed. (click on the 'broken image' link to download the patch)

Sample Patch Demonstrating Listbox feeding Fader

[sephult]

Thanks for the detail and patch share shawnb.

You are right there are many different techniques on how to wire things.
It is strange though as I do not see the quirkiness you are describing. It seems in my setup even a pass if change is dead on solid.
I do not see any difference, however you do make a good point in development of patches and compatibility, sometimes the techniques used can have quirks in other setups. Would be interesting to pinpoint where you are seeing quirks and I am not.

So does the fader not update to the listbox value in some instances with just a pass if changed?

Now it is true if a value is on a wire or node, it will not change if the same value is present. It must change and refresh that value to have an indication to be read that it changed, or extra control logic must be used to indicate the change. From a programmers point of view, this can be confusing as every event change is expected to be read and indicated. When I first started using HH, I ran into this confusion as well and found I had to work around this behavior.





If you add the round and pass if changed and feed back, you can update your listbox to reference your fader so they can at least be in step.

Makes me want to start a "patch creation" post where one person adds a module, and the next adds another and so on.
Wonder what we could come up with

-S

[shawnb]

Thanks for the detail and patch share shawnb.
It is strange though as I do not see the quirkiness you are describing. It seems in my setup even a pass if change is dead on solid.

The "Pass if changed" technique doesn't work whenever the listbox's previous value is selected. In my sample code, for the "pass if changed" example, if you select "2" in the listbox, then use the fader to change it to .75, then click on the "2" in the listbox, the fader & value will not be updated to 2. From the listbox's perspective, nothing changed, so the 2 is not passed. This was driving me nuts...

So does the fader not update to the listbox value in some instances with just a pass if changed?
...
If you add the round and pass if changed and feed back, you can update your listbox to reference your fader so they can at least be in step.

That's a good idea. I used a different technique...

The fader cannot accurately update the listbox, since the listbox represents only a few discrete values (e.g. integers). Usually the fader can represent "infinitely" more values (e.g. fractions).

Rather than trying to update the value of the listbox from the fader, I prefer to hide the cursor of the listbox when the fader is used.

The current CC Generator add-on uses a mousedown on the fader to change the color of the cursor on the listbox, hiding it, avoiding the confusion.

[sephult]

shawnb wrote:
The "Pass if changed" technique doesn't work whenever the listbox's previous value is selected. In my sample code, for the "pass if changed" example, if you select "2" in the listbox, then use the fader to change it to .75, then click on the "2" in the listbox, the fader & value will not be updated to 2. From the listbox's perspective, nothing changed, so the 2 is not passed. This was driving me nuts...

Okay I get what you mean regarding, sending the same value twice...essentially the same thing I was describing later in my reply. And yes I agree...it took me quite awhile to get that fact in my head....once a value, stays a value until changed.

Regarding the feedback:

The problem obviously is floating point to integer conversion, you are right data-scaling etc, all have some point of error, where like a .43 will be a 1. One of the reasons Ill do the rounding on most float-integers, as I recall I think in all cases that is the majority of ways even to Fastscript convert from float to int.

I did notice that in your CC Generator add-on, I was wondering why you had done it that way. Interesting to find out how others approach patching. Definitely like to see examples and tutorials. Hopefully sometime soon ill develop some and you can help me refine and we can share for reference. I like how you laid that example out