hmm, this looks promising. But I don’t know how to implement it. I’ll experiment, but do you know how I would add (interpAccelDecel(#Ds#, 0, 60)) to this $#VAR_1#==1?#DWFSS#:90$ ?
Still stuck on this problem, but I happened to see a face this morning which had a dimensional transition activated by a tap action. Presumably in that face the code was placed in the height/width field. The basic point A and B were probably something like this:
$#VAR_1#==1? 320:0$
But with something added to create a smooth transition between 0 and 320
Whatever that transition code is would seem to be what I’m looking for to get between point A and B in the rotational field.
Can anyone share an example of this code as applied to the height/width of an object?
I’m going to assume it works the same way. Even for those interpAccelDecel functions, you need some var for keeping the start time of the transition, and the transition true/false.
I checked the docs again, and basically you already have your “VAR_2” available:
TAG
DEFINITION
EXAMPLE OUTPUT
#VAR_1#
Value for interactive variable 1
12
#VAR_1_T#
Timestamp at which interactive variable 1 was last updated
1550780123
I cannot really test without pro, but does this work for the Second hand (remove the line breaks): $#VAR_1#==1&&#DNOW#<(#VAR_1_T#+1000)?((15/60*360) + ((#VAR_1_T# + 1000 - #DNOW#) / 1000 * (#DWFSS# - (15/60*360)))):$ $#VAR_1#==1&&#DNOW#>=(#VAR_1_T#+1000)?(15/60*360):$ $#VAR_1#==0&&#DNOW#<(#VAR_1_T#+1000)?(#DWFSS# + ((#VAR_1_T# + 1000 - #DNOW#) / 1000 * ((15/60*360) - #DWFSS#))):$ $#VAR_1#==0&&#DNOW#>=(#VAR_1_T#+1000)?#DWFSS#:$
that does work in the creator yielding smooth transition between points a and b. But on my watch it still jumps. I may as well say that for simplicity I was giving seconds hand as an example but in reality I’m applying this to a moon phase. And in fact when I plug the moonphase code in place of the all the instances of #DWFSS# it works just as is does with the seconds hand, so that’s a success, but likewise, still jumps in the watch. So still a no-go. But very much appreciate your help! Getting closer!
@Rator@GAUSS you guys both use smooth transitions in some faces, anything you care to share to help me solve this problem? Surely it’s simpler than all this.
again, basic goal is to take this:
$#VAR_1#==1?#DWFSS#:90$
but create a smooth transition between points A and B
I struggled to understand interpAccel and related functions until I read this mini-tutorial by @eradicator09
My beating heart face uses those functions for hand wake up when transitioning from dim to active (part of what you are looking for) as well as to implement the beating heart in the centre.
(just ignore the crude graphics for hands and heart used on the face looks fine to me on a small watch screen, not so good on a larger higher resolution screen.)
@mountain_lion Thanks for all this… I feel like the answer is in there. I’m digging. One question I have, all of these examples are using the wake up #DWE# as a trigger. How do I have the Tap action be the trigger? Is there an expression specifically for that?
So I’ve been experimenting with quite a number of variations based on the tutorial/example. If I use DWE as the “Time Format” as it is in those examples. It makes the hand sweep in transition only the first tap. Subsequent taps just jump between A and B. Many of the variations I use still have the functioning effect of jumping between A and B basically ignoring all the additional code but not breaking down completely. Here’s an example:
I think you need to use the interpaccel thingy. Here’s the code that you’re talking about…
$#VAR_1#=1?(10+(interpAccel((#DNOW#-#VAR_1_T#),0,1000,1)*310)):(320-(interpAccel((#DNOW#-#VAR_1_T#),0,1000,1)*310))$
I was on the right track, and one thing I changed seeing your code is the value for min/max. the examples I was drawing from had small numbers but I see you have 1000. So I was thinking that value is seconds, but is it milliseconds? Anyway, I’ve got this plugged into a test hand rotation now:
It starts fixed on 90 as I want, tap action causes smooth sweep to DWFSS as I want, BUT the return starts from 0 and goes clockwise. So now the last piece of the puzzle is to get the second tap to start from the current position in DWFSS and smoothly sweep counter clockwise back to 90.
the destination (*90) is relative to the starting point. So I have to be able to specify both the start and finish points in fixed terms or the hand will keep rotating. But the start point is always dependent on the current position of DWFSS so if I assign 90 to the destination the start point has to be 180.
I can see what needs to be expressed but I don’t know how to properly express it.
Basically I need my start position to be a static number determined by current second, like X=#Ds# and then for my destination I need to call that value and extrapolate the distance to return to 90
#DWE# is in seconds, #DNOW# and #VAR_X_T# are in milliseconds
In essence there is no difference in the example I gave you, and using interpAccel/Decel. I did the calculation manually, and you get a linear transition, using interpAccel or interpDecel will give you an ease-in or ease-out transition:
(The interpAccelDecel does not work on my fossil)
You still need the same things for a transition:
A starting point
An end point
A starting time
An end time
There are 4 states:
At 90 degrees
Transition towards #DWFSS#
At #DWFSS#
Transition towards 90 degrees
This means you need either 4 conditions in one, or you have 2 conditions in 2 elements and set the right element’s opacity to 100 or 0
Yes this is possible, it is what I did in the example I gave you.
Could you share your current draft with inspection on, so we can see exactly what you have now, or, since the example I gave you works in designer, you could try to figure out what part does not work on your watch and see if adjustments can be made (sometimes it is silly things like using or omitting brackets).
and you can also see the issue of the second hand. one reason I didn’t continue to explore your manually calculated lengthy code is because in the end I’ll be replacing any instance of DWFSS with a moonphase code. And I really don’t understand most of what was happening in your example. This shorter method with interpaccel at least makes sense to me and I can figure out the elements that I need to modify.
This code I’m using works just as well with the moonphase code as with DWFSS, but it’s less messy to work this out with DWFSS
Inspection doesn’t seem to work. However, what I see here is, in the left part you use #DWFSS# in your expression, on the right part you use hard coded 180 and 90, so that part will never travel considering the seconds position.
Try: $#VAR_3#==1?(90+(interpAccel((#DNOW#-#VAR_3_T#),0,1000,1) * #DWFSS#)):(#DWFSS#-(interpAccel((#DNOW#-#VAR_3_T#),0,1000,1) * (#DWFSS#-90)))$
I’m going to try this out in a few moments. I fear what’s going to happen is when going back to 90 it will resume dwfss from there instead of parking. I’ll let you know. If that’s the case though and everything else it’s proper than perhaps a round about solution will be an extra layer that’s permanently parked at 90 and code the opacity to show/hide in conjunction with this one. Hmmm…
Also, I tried everyway I could see to share the draft test face but none of them seemed to give an icon to inspect (it’s definitely enabled). How best to share so you can see it?
Thanks so much for the help! It’s an amazing watch if I’m able to complete it!
I do not have any VAR, so I can only test the true or the false part of the expression seperately, but the 2 #DWFSS# should cancel each other out.
Only thing to keep in mind is, I think from 0 to 15 seconds will travel clockwise and 15 to 60 will travel counter clockwise when parking (and vise versa when returning)
I have no clue if inspect works with drafts at all.
well, good news/bad news. The good news is it does indeed park, which I don’t understand because everything I had tried that included a rotation as the starting point did not park.
I think I’ve figured out a way to share the inspect view:
looks fine to me on a small watch screen, not so good on a larger higher resolution screen.)