Mouse Drag float outputs

[tor]

I found a bug in the Mouse Drag prims. Seems like they produce 2 ticks pr float change in the outputs. Workaround: Insert a Float Changed module right after all mouse drag prims to reduce all green calculations with prox 50%.

Mail sendt to support

[infuzion]

Might be that there are 2 values generated, but they don't output differently due to 32bit rounding?

[tor]

Could be.. but then it's strange that it happens for every second output.
Anyway, the Float Change or an equal function should be implemented into the Mouse Drag prims to reduce triggers and extra work.

[Mo]

Actually it's not two ticks per float change but ticks from all mouse activation, including mouse click up/down. If you count the triggers from float changed and add the triggers from the "dragging" output you should see the same amount triggers when dragging between the min. and max. value. BTW a "float change" module should be standard on all knobs and sliders as it also blocks the triggers after min/max are reached.

[aliasant]

This is not a bug but a feature.

Not sure if this is documented in the manuals though. Never read em..

[tor]

Well, I concider it a bug cause it is a unwanted, unnecessary and cpu increasing behaviour. Many small rivers turn into a ocean.

[trogluddite]

I'm with Tor on this one. We have separate Mouse button, Mouse over etc. primitives - I would prefer to add primitives for the other events explicitly when they are needed, instead of having to suppress the 'extra' triggers that come out of the Drag accumulators.

[tor]

Actually it's not two ticks per float change but ticks from all mouse activation, including mouse click up/down. If you count the triggers from float changed and add the triggers from the "dragging" output you should see the same amount triggers when dragging between the min. and max. value. BTW a "float change" module should be standard on all knobs and sliders as it also blocks the triggers after min/max are reached.

At the Min/Max was where i got aware of this behaviour. I did some research and after adding the Float Changed right after the Mouse Drag prim the number of ticks at Min/Max is the same whether or not I have a Float Changed after it.

[tor]

Now I just realized that the Float Changed prim after the Mouse Drag stops triggers from the Ctrl Click/reset funktion in the knob. So it alone is not a good workaround anyway.

Sorry

[tor]

Solved... hopefully.

Also remove the float select connected to the float output in the control module (same as you find the mose drag in)

Can anyone confirm that this solution does not create any further problems?

[tor]

Edit: Here was a example.

[tor]

Nah.. it is not good. Still working on it

[trogluddite]

I think the float select is there to limit the triggers when the knob is moved by the MIDI CC or VST automation - so it may be worth seeing what happens when you send data into the knob from those two places.

There is also a further ReDraw optimisation that you can do...
The 'Areas' module has an integer 'Cell' input to choose the animation frame - you can put an 'Integer Changed' leading into that input, so that the Areas are only calculated if a new frame is needed (the trigger blocker also has to be moved). Then, also take the ReDraw trigger from the Integer changed - that will stop it from ReDrawing the same frame if the mouse movement is very small.

Less Knob Drawing.png (56.55 KiB) Viewed 1655 times

[tor]

He he.. I sort of ended up redesign almost the whole knob. Thanks for your tips trog
Think I have it all sorted out now.

EDIT: Fixed input source to Set on Drag Prim. Now it function correct.

Here it is:

Knob.osm

(35.63 KiB) Downloaded 138 times

[infuzion]

He he.. I sort of ended up redesign almost the whole knob... Think I have it all sorted out now.

Looks clean, thanks!