trigger events from a knob

[gvalletto]

Hi all,
When I want to know how many trigger events a knob generates, I only connect a trigger counter to the float output of the knob. Obviously, the number of counts depends on how fast (or slow) I move the knob.
Now I want to know if the number of trigger events would be the same on different computers when they come from similar events.
How that trigger events are generated in cases like this, that is, from a continue variable like a float knob output?
Depend them on the sampling rate or something else?

Thanks in advance,
Gustavo

[Nubeat7]

afaik it depends on the mouse update rate..??

so it will not be the same on every computer, anyways you should use a trigger limiter, then it should be about the same on different machines..

[Wassaka]

I think the number of triggers per second varies depending on the CPU state in your plugin. For example, if you have occupied 1% of the CPU in the plugin, obviously the tickrate will be higher than if you have the CPU occupied by 50% ... Anyway the information limit per second of a float is 100 Ticks.
As well said Nubeat7, put a trigger limiter to make sure that all computers will have at least that tickrate, eg: 20 ticks.
Hope it Helps!!

[martinvicanek]

Hm, I think if you don't move fast you get a trigger each time you advance by a pixel. For fast movement there may be some computer dependent limitation as stated above.

[nix]

I think it could be jigged to produce pretty consistent(at least) triggers if you need it.
Ruby would help.

[tulamide]

Martin pretty much nails it. There's a low end of 1 trigger per pixel movement of the mouse, but there's no fixed maximum. It depends on so many factors, like mouse tracking speed, system mouse event speed, or if you currently execute a mouse event in which case you lose the newly incoming one, etc.

Never depend on a certain amount of triggers.

[Spogg]

I've also noticed that the mouse response can be different in the exported VST to the FS edit environment. So I would always test in an export (Green stuff generally seems faster in a VST than in the editor).

Cheers

Spogg

[nix]

Sure, it doesn't necessarily depend on the mouse's speed.
What about turning a timer on on on mouse down, and turning it off on mouse up,
plus mouse up trigger to set final position, with the trigger blocked from the mouse position?
Does that make sense?

[tulamide]

Sure, it doesn't necessarily depend on the mouse's speed.
What about turning a timer on on on mouse down, and turning it off on mouse up,
plus mouse up trigger to set final position, with the trigger blocked from the mouse position?
Does that make sense?

That's again trying to be dependend on triggers.

Never depend on a certain amount of triggers.

Consistency in computing is reached only with interpolation. In case of green/Ruby that means using deltatime. dt is the time passed between the next-to-last and last trigger and used to get a constant over time action.

x * dt means "x times per second", when dt is recalculated on every new trigger. Say you want to move a slider smoothly by 100 pixels over a period of 1 second. You don't know how many triggers will occur, and you don't need to. With dt it will be 100 pixels per second, no matter the amount of triggers.

Say, triggers come in at 0.05, 0.1, 0.25, 0.3, 0.5, 0.55, 0.6, 0.65, 0.7, 0.85, 0.95, 1 (display in seconds)

Your calculation (see above) would be 100 * dt as the portion of movement for a trigger. You just need dt.

trigger 1
dt = 0.05 - 0.0 = 0.05; 100 * 0.05 = 5 pixel translation at this trigger

trigger 2
dt = 0.1 - 0.05 = 0.05; 100 * 0.05 = 5 pixel translation at this trigger

trigger 3
dt = 0.25 - 0.1 = 0.15; 100 * 0.15 = 15 pixel translation at this trigger

trigger 4
dt = 0.3 - 0.0 = 0.25; 100 * 0.05 = 5 pixel translation at this trigger

trigger 5
dt = 0.5 - 0.3 = 0.2; 100 * 0.2 = 20 pixel translation at this trigger

trigger 6 to 9
100 * 0.05 = 5 pixel translation at each trigger

trigger 10
dt = 0.85 - 0.7 = 0.15; 100 * 0.15 = 15 pixel translation at this trigger

trigger 11
dt = 0.95 - 0.85 = 0.1; 100 * 0.1 = 10 pixel translation at this trigger

trigger 12
dt = 1.0 - 0.95 = 0.05; 100 * 0.05 = 5 pixel translation at this trigger

This covers one second. Let's add the translations:
5 + 5 + 15 + 5 + 20 + 5 + 5 + 5 + 5 + 15 + 10 + 5 = 100 pixel total

This works wherever you need a stable progress over time.

You don't need it in blue or white, since there everything is already based on a stable progress - the samplerate.

[nix]

Interesting about the delta time theory.
How is that implemented?

All the same , Ruby time is pretty good,
more than the quasi-random output of the mouse movements.
This would provide a degree of similarity across different user's systems-
if that's needed
I think it's a hold that would be triggered?