Timer op bug with really low speed values

After working around with some really low values for the timer for an effect - I recognised that the timer always started with a 1, even if i set it lower at a value like 0.0000000001 and reloaded the patch.
It seems to work if the timer is already running - but if you reload it doesn´ t work anymore and if you reset - you can see that first it jumps already to higher value if it is then set (that might give you a nice hiccup in your effect at the start)- and sometimes it is not - so it just runs with the full “1” speed.

I tried to adjust the code of the op - but after breaking the whole patch beyond the point of repair twice (Script error.file: / row:0 ? ) - I have given up.

So far I can´t say that if the reasons might be a problem from the interface (it changes the values from 0.0000000000001 to the “1e-12” notation if you reload - which might be value wise correct but maybe interpret wrong from the .get() Method or the default values of the instanced CABLES.Timer() Object or there is simply just a missing update of the timer offset.But for that I am missing the insight of the CABLES.Timer() Object. If the op is already running, that doesn´´t matter. It adjust the time just fine for the position after the comma.

So far just my assumptions. Best wishes for the new year to all @cable.gl ;).

hey,

can’t you just use a “divide” op after your timer to make it “slow down”? i know this
does not really change the speed of the increment, but might be a workaround. the
change to “scientific notation” we have to check…

cheers,
stephan

for what it’s worth, it starts changing to “scientific notation” at 0.0000001. unfortunately this even happens when you do the math “before” the timer, i.e. inputting number and divide into “speed”…

even the way to multiply with a smaller number like 0.0000001 after the timer is changed doesn´t work - so the only way for a workaround so far is just to write an own op or to change the speed value as the timer is already running in edit mode - as a fact then the op creates the correct speed with a real small value as planed. Strange.

this seems to be what is going wrong here, when displaying for the “editor input field” javascript converts to scientific notation, then we use that as a string to input…then it fails. if you write your own op you may check for “e” in the “number” then convert…or something hacky like this…

Possible. It also might be that the problem is similiar with the problems described in this thread: https://stackoverflow.com/questions/6233927/microsecond-timing-in-javascript
But for that I have not enough insight into the cables src.

ok - missed this one: as it goes more into the details like the other post: https://stackoverflow.com/questions/6875625/does-javascript-provide-a-high-resolution-timer/10767937#10767937
But I promise I stop here - so far I just give some guesses here :wink: