From the original SynthMaker forum (2004–2014), with its members’ names and dates.
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 ·
Mo wrote: 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.
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:
infuzion ·
tor wrote: He he.. I sort of ended up redesign almost the whole knob... Think I have it all sorted out now.
Looks clean, thanks!
Mo ·
tor wrote: Think I have it all sorted out now.
I'm sure no "set" from preset to the drag accumulate can make some problems. Try test it with automation and preset change. Also, placing the Float Change after the step module is better if you use steps. Hold default and drag, makes the knob skip.
aliasant ·
Nice Tor. A lot better design but theres a small bug. Try using it with a Preset Manager. Set the knob so something low save and go to next preset. Set it to something high save and go back to previous and start interacting with the knob. I think you need to get the current value from the preset primitive into the Set input on the drag prim.
tor ·
Thank you Mo n aliasant. Set is now fixed 🙂
tor ·
Is there any solution to this problem?
The mouse drag prims continue to registrate mouse movement after they reached min or max. So if the user drags up beyond max some distance with the mouse, he will have to drag the same distance down again before the knob value decrease and knob moves again if not mouse button released meanwhile.
All SM knobs behaves like this.
Should we consider this a bug or is it supposed to be this way? If so why.......
Tor
adamszabo ·
Yeh its wierd... I tried to do a fix but no luck.
Mo ·
tor wrote: The mouse drag prims continue to registrate mouse movement after they reached min or max. So if the user drags up beyond max some distance with the mouse, he will have to drag the same distance down again before the knob value decrease and knob moves again if not mouse button released meanwhile.
Posted about this some time ago: Hide and hold. Now i set the Drag Accumulate's cursor input to "1=hide and hold" only, i think it's better.
trogluddite ·
The upside of it is that it works better when you have a graphical 'icon' that you drag around (e.g. a 'handle' on a graphical envelope) - the mouse pointer will stay glued to the handle even if you go outside its display area and then re-enter. I'd still be in favour of a purely 'drag direction' accumulator as an alternative for knobs though.
tor ·
trogluddite wrote: The upside of it is that it works better when you have a graphical 'icon' that you drag around (e.g. a 'handle' on a graphical envelope) - the mouse pointer will stay glued to the handle even if you go outside its display area and then re-enter. I'd still be in favour of a purely 'drag direction' accumulator as an alternative for knobs though.
1+
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker