MIDI Kinetics Forum

So I have the pictured fader accepting values from the pad in the bottom right corner. Holding the pad down will increase the faders value according to the Attack of the fader, letting go will cause the fader to decrease in value according to the Release value of the pad (I am not utilizing decay or sustain at the moment). The second smaller Pad (above the bottom right Pad) will set the hold value of the main pad to 1 when held. Touching the fader will override the main pad that controls its value, and instead lock the fader in the position you drag it to.
I am happy with this functionality but would also like a pad/button to decrease the faders value down to 0 according to the Release value of the pad when the fader has been locked... As of now, quickly tapping the Pad in the bottom right corner will slightly increase the value of the fader and then decease it as desired. This is almost what I want...

So, the easiest solution (if possible) would be to somehow script a button that would fool the pad into thinking it was very breifly activated, thus it will do the rest. Note that simply changing the x value of the pad will lock it in this new position, not cause its brightness to fade as desired. Is this method possible and if so how?

Another solution would be to mimic whatever code causes the pads value to decrease and feed it the release value from the pad... Could someone help with this if the first idea is not viable?

Or perhaps someone has a better idea? Thanks.

Okay, this tutorial helps a bit as far as programming the decrease in value however, since it uses on frame execution and the frame rate can vary it is not a viable means by which to control the exact time it takes to decrease the value to 0 (in other words, accurately reproduce the release of the pad).

Is there some way to access the frame rate lemur is operating at so that I can factor this in correctly?

If not, how often, and when will I know that lemur is operating at below 60 frames per second?

Hi
I believe that was more relevant to the hardware though there will be carry over of the underlying reason also I think . . .
It would probably only come into play with very complex projects and possibly visually complex as well . . .
I am not sure how much drift there is possibly going to be but suspect that it would be fairly minimal . .
Cheers
MM

I got it roughed out.
-I run an on frame script that adds +1 to a global variable for ever iteration in a given second.
-Once that second ends this count is stored in another global variable to get the FPS for that pas second, and the counter is reset.
-This gives a decent FPS readout.
-With the FPS, it is possible to break out the current X value of the fader into how much I want to decrease it by for each frame (have to assume the FPS will be somewhat consistent, a bit of a fault but the best I can do).
-So basically
-Then I set another global variable, 'fadingOut' to flag that a fadeOut is in progress.
-Within the pad, I add an onFrame Script that will decrease Fader.x by the decreasePerFrame value when the fadingOut Flag is true,
-Finally, when the Fader.x is <=0, I set the fadingOut flag to false.
-also did some work to disable the fade out if the fader is touched but the beef of the work is above...

Here's the dev template:

I've been re-reading section 13.5 of the manual regarding the Built-In Time Variable

A few questions that maybe somone can help me with.

They list a couple of ways to manipulate the time variable, one of them is:
Utilizing this method would certainly be easier and lighter than my way of doing things (adding one frame to the counter on every frame, and resetting it after a second). However, the value this formula produce seems to have no bearing what soever on the actual frame rate? Can someone explain what is going on (or supposed to be going on) in that example? The best I can tell is that it works on the assumption that the frame rate is always so many frames per second, and uses that assumed FPS against the time to generate a readout. When I run that formula in a monitor, it never peeks over 30, as opposed to my counter which hovers between 58 - 63 (and seems more accurate as per the expected 60 FPS).

Secondly, at the end of the section it states:

You can assign time-based variables to properties in Lemur Objects (such as Friction or the ADSR
envelopes) to create Objects that change over time.

Am I working too hard to achieve the fade out effect on the fader?