MIDI Kinetics Forum

I am still unclear as to whether Lemur always runs at 60 FPS, but logic tells me it does not.

I have created a small module that tracks FPS via an onFrame script, as well as gives an efficiency readout compared to peak FPS ( current FPS / 60 )...

I've dropped it into different templates and gotten different results. I've been doing more with intervals (automatic timed fade outs and the like) and have been using this as a reference tool.

The editor will sometimes run at 62 or 63 FPS for me, but once dropped into a template by itself the counter holds steady at or below 60 FPS

http://liine.net/en/community/user-library/view/369/

Interesting...

That's a nice thing to have, thanks Traxus.

great stuff
all these tools are useful just to drag in from the library when needed
I use this to monitor frame rate , definitely not a constant, doesnt take much to slow it down

I find it particularly handy for time sensitive actions that don't necessarily have a definite start and end point.

For instance, I needed an encoder to complete a rotation every ~2 seconds. Of course, you add to the x value of the encoder onFrame, but how much you add is dependent on the current frame rate. Lower frame rates = more added to the x value every frame to maintain the 2 second cycle.

Traxus wrote:I find it particularly handy for time sensitive actions that don't necessarily have a definite start and end point.

For instance, I needed an encoder to complete a rotation every ~2 seconds. Of course, you add to the x value of the encoder onFrame, but how much you add is dependent on the current frame rate. Lower frame rates = more added to the x value every frame to maintain the 2 second cycle.

I was revisiting this last night, and realized the better way to do it is by calculating the time between intervals (frames), as well as calculating the expected distance to be traveled during that amount of time, rather than tying it directly into FPS. You end up one frame behind but at worse that's like 1/30th of a second so no big deal.

I had actually figured all this out awhile ago, and then forgot how I did it.

In other words, you can use the FPS value directly but its better used as a monitor to the weight of your template.

Hi
For things like this I would link them to time() directly using it for the phase. . .
Something like a function phasor(timer) - (time*1/timer)%1
Then for the 2 second rotation Knob a script - x=phasor(2) will do what you want . . .
MM

Macciza wrote:Hi
For things like this I would link them to time() directly using it for the phase. . .
Something like a function phasor(timer) - (time*1/timer)%1
Then for the 2 second rotation Knob a script - x=phasor(2) will do what you want . . .
MM

I think the problem I would have with that is, on release of a scratch action, the x position would jump to the position expected by that calculation rather than resume from its current spot. This could be worked around, but my intuition is the work around would then be heavier than what I've got, I'd have to revisit it.

I believe I've used a similar solution to what you've proposed for simpler applications like automated fade outs where there are less potential factors altering the x position.

Aah thats a bit different then
Did not realise you wanted to be able to 'scratch' it . .
For that you would need to introduce 'phase' or 'phase angle' into it
Then it would simply inhibit the phasor when scratching (z=1) and then set a new phase position when z returns to 0 . . .
Cheers