Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Geoff, It does have a certain elegance to it --and it preserves the subject header of 17 LINES of CODE ;-) The 3 MINUTES has grown just a tad to get it to it's current evolution. I just don't like the long math line to get the hours straight -- could there be a simpler way? Now all we need is a deep bitmask clockface to make it pretty. Perhaps a chime or coo-coo and an alarm setting to make it a fully functional simulation. These would be easy using the same delayed handler idea. Dennis On Jun 9, 2005, at 10:15 AM, Geoff Canyon wrote: I think the separate handlers solution is the way to go, even if it does mean a few more lines of code. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On Jun 9, 2005, at 5:51 AM, Dennis Brown wrote: I also just took out the hour 'if' statement in yours, so that minutes and hours are updated together after only 10 seconds from start. The extra time for doing the hours every ten seconds is trivial. But that's just...wrong ;-) I just sent a reply to your other email -- I think the separate handlers solution is the way to go, even if it does mean a few more lines of code. gc ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I considered this option and went the other way for a couple reasons. It seemed more natural to leave it in one handler. It takes more lines of code to split the handlers up. I wonder what the overhead is to have three messages pending as opposed to one. That said, I think this is the way to go. It solves the display-isn't- right-for-up-to-two-minutes problem, and the implementation is about as clean as can be. I think we may finally be close to the optimum solution. gc On Jun 8, 2005, at 9:35 AM, Dennis Brown wrote: Geoff, Your new idea gave me an idea. Make three handlers --one for each hand (I hope I got the hour math straight) You can find it in my user space (see3d). Dennis on openCard setSeconds; setMinutes; setHours end openCard on setSeconds send setSeconds to me in 1-(the long seconds mod 1) seconds put the long time into fld "Time" --8:13:15 AM set the angle of grc "Second" to 450 - ((the seconds * 6) mod 360) end setSeconds on setMinutes send setMinutes to me in 10-(the seconds mod 10) seconds --10 seconds/degree set the angle of grc "Minute" to 450 - ((the seconds mod 3600) div 10) end setMinutes on setHours send setHours to me in 120-(the seconds mod 120) seconds --120 seconds/degree set itemdel to ":" set the angle of grc "Hour" to 450-(60*item 1 of the time mod 12) - ((the seconds mod 3600) div 120) --It's UTC if you just use the seconds here end setHours On Jun 8, 2005, at 10:04 AM, Geoff Canyon wrote: I came up with a radically different approach. Several iterations ago, we realized that we didn't have to guess when it would be time to set the clock graphics. We could use 1-(the long seconds mod 1) to get a message sent exactly when we need it. Well, we're still guessing at when it's time to move the minute hand or the hour hand, and we don't need to. The minute hand moves one degree every ten seconds, the hour hand one degree every two minutes. The tests to determine this are simple. The natural thing to do is set the second hand, check to see if the minute hand needs to be set, and if it does check to see if the hour hand needs to be set. At each step, I want to exit if appropriate. The stumbling block was the send...in. I need to get to the end to do it. Then I realized -- the send...in doesn't have to be the last step. It can come at any point. So here's the script now: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Geoff, I also just took out the hour 'if' statement in yours, so that minutes and hours are updated together after only 10 seconds from start. The extra time for doing the hours every ten seconds is trivial. Dennis On Jun 9, 2005, at 1:12 AM, Geoff Canyon wrote: On Jun 8, 2005, at 8:40 AM, Eric Chatonet wrote: Just a little thing: with this new very clever code, the clock will not be at time just when opening ;-) So 4 lines more and 2 repetitions that are not satisfying: I bet you will find a better solution in 3 minutes! Thanks for the compliment. I'm not sure I would find a better way. I thought about this issue and decided to ignore it this morning because I didn't have time to do something better. Your way, passing in an argument to force an update, is likely the best with this particular design, although have a look at the example Dar suggested and Dennis posted. Separating the movement of the three hands into three separate handlers gets past this problem. gc ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On Jun 8, 2005, at 8:40 AM, Eric Chatonet wrote: Just a little thing: with this new very clever code, the clock will not be at time just when opening ;-) So 4 lines more and 2 repetitions that are not satisfying: I bet you will find a better solution in 3 minutes! Thanks for the compliment. I'm not sure I would find a better way. I thought about this issue and decided to ignore it this morning because I didn't have time to do something better. Your way, passing in an argument to force an update, is likely the best with this particular design, although have a look at the example Dar suggested and Dennis posted. Separating the movement of the three hands into three separate handlers gets past this problem. gc ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Geoff, Your new idea gave me an idea. Make three handlers --one for each hand (I hope I got the hour math straight) You can find it in my user space (see3d). Dennis on openCard setSeconds; setMinutes; setHours end openCard on setSeconds send setSeconds to me in 1-(the long seconds mod 1) seconds put the long time into fld "Time" --8:13:15 AM set the angle of grc "Second" to 450 - ((the seconds * 6) mod 360) end setSeconds on setMinutes send setMinutes to me in 10-(the seconds mod 10) seconds --10 seconds/degree set the angle of grc "Minute" to 450 - ((the seconds mod 3600) div 10) end setMinutes on setHours send setHours to me in 120-(the seconds mod 120) seconds --120 seconds/degree set itemdel to ":" set the angle of grc "Hour" to 450-(60*item 1 of the time mod 12) - ((the seconds mod 3600) div 120) --It's UTC if you just use the seconds here end setHours On Jun 8, 2005, at 10:04 AM, Geoff Canyon wrote: I came up with a radically different approach. Several iterations ago, we realized that we didn't have to guess when it would be time to set the clock graphics. We could use 1-(the long seconds mod 1) to get a message sent exactly when we need it. Well, we're still guessing at when it's time to move the minute hand or the hour hand, and we don't need to. The minute hand moves one degree every ten seconds, the hour hand one degree every two minutes. The tests to determine this are simple. The natural thing to do is set the second hand, check to see if the minute hand needs to be set, and if it does check to see if the hour hand needs to be set. At each step, I want to exit if appropriate. The stumbling block was the send...in. I need to get to the end to do it. Then I realized -- the send...in doesn't have to be the last step. It can come at any point. So here's the script now: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Hi Scott, I'm afraid preOpenCard instead of openCard will not solve the problem. In the worst case, you will have to wait 9 seconds to see the minutes hand correctly positionned and almost 2 minutes for the hours one. Best regards from Paris, Eric Chatonet. Le 8 juin 05 à 18:14, Scott Rossi a écrit : Recently, Eric Chatonet wrote: on openCard setTime end openCard on setTime send "setTime" to me in 1 - (the long seconds mod 1) seconds put word 1 of the long time into T --8:13:15 put T & char 2 to 7 of (the long seconds mod 1) into fld "Time" split T using ":" set the angle of grc "Second" to 450 - (6 * T[3]) if T[3] mod 10 <> 0 then exit setTime set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) if T[3] <> 0 or T[2] mod 2 <> 0 then exit setTime set the angle of grc "Hour" to 90 - (30 * T[1]) - (T[2] div 2) end setTime Very impressed to see how much a code can be improved again and again. Just a little thing: with this new very clever code, the clock will not be at time just when opening ;-) So 4 lines more and 2 repetitions that are not satisfying: I bet you will find a better solution in 3 minutes! If I understand your comment, I believe all you need to do is change "on openCard" to "on preOpenCard" -- no extra lines needed. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Plugins, tutorials and more on our website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Recently, Eric Chatonet wrote: > on openCard > setTime > end openCard > > on setTime > send "setTime" to me in 1 - (the long seconds mod 1) seconds > put word 1 of the long time into T --8:13:15 > put T & char 2 to 7 of (the long seconds mod 1) into fld "Time" > split T using ":" > set the angle of grc "Second" to 450 - (6 * T[3]) > if T[3] mod 10 <> 0 then exit setTime > set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) > if T[3] <> 0 or T[2] mod 2 <> 0 then exit setTime > set the angle of grc "Hour" to 90 - (30 * T[1]) - (T[2] div 2) > end setTime > Very impressed to see how much a code can be improved again and again. > Just a little thing: with this new very clever code, the clock will > not be at time just when opening ;-) > So 4 lines more and 2 repetitions that are not satisfying: I bet you > will find a better solution in 3 minutes! If I understand your comment, I believe all you need to do is change "on openCard" to "on preOpenCard" -- no extra lines needed. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On Jun 8, 2005, at 8:04 AM, Geoff Canyon wrote: Let me know what you think. You can even put the advance for the minute hand and for the hour hand in separate send cycles that can be approximate. Dar -- ** DSC (Dar Scott Consulting & Dar's Lab) http://www.swcp.com/dsc/ Yahoo! RevCon West in 10 days! ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Hi Geoff, Kudos. Very impressed to see how much a code can be improved again and again. Just a little thing: with this new very clever code, the clock will not be at time just when opening ;-) So 4 lines more and 2 repetitions that are not satisfying: I bet you will find a better solution in 3 minutes! on openCard setTime true end openCard on setTime pFlag send "setTime" to me in 1 - (the long seconds mod 1) seconds put word 1 of the long time into T --8:13:15 put T & char 2 to 7 of (the long seconds mod 1) into fld "Time" split T using ":" set the angle of grc "Second" to 450 - (6 * T[3]) if pFlag then set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) set the angle of grc "Hour" to 90 - (30 * T[1]) - (T[2] div 2) end if if T[3] mod 10 <> 0 then exit setTime set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) if T[3] <> 0 or T[2] mod 2 <> 0 then exit setTime set the angle of grc "Hour" to 90 - (30 * T[1]) - (T[2] div 2) end setTime Best regards from Paris, Eric Chatonet. Le 8 juin 05 à 16:04, Geoff Canyon a écrit : I came up with a radically different approach. Several iterations ago, we realized that we didn't have to guess when it would be time to set the clock graphics. We could use 1-(the long seconds mod 1) to get a message sent exactly when we need it. Well, we're still guessing at when it's time to move the minute hand or the hour hand, and we don't need to. The minute hand moves one degree every ten seconds, the hour hand one degree every two minutes. The tests to determine this are simple. The natural thing to do is set the second hand, check to see if the minute hand needs to be set, and if it does check to see if the hour hand needs to be set. At each step, I want to exit if appropriate. The stumbling block was the send...in. I need to get to the end to do it. Then I realized -- the send...in doesn't have to be the last step. It can come at any point. So here's the script now: on openCard setTime end openCard on setTime send "setTime" to me in 1 - (the long seconds mod 1) seconds put word 1 of the long time into T --8:13:15 put T & char 2 to 7 of (the long seconds mod 1) into fld "Time" split T using ":" set the angle of grc "Second" to 450 - (6 * T[3]) if T[3] mod 10 <> 0 then exit setTime set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) if T[3] <> 0 or T[2] mod 2 <> 0 then exit setTime set the angle of grc "Hour" to 90 - (30 * T[1]) - (T[2] div 2) end setTime Notice how simple the check is for the minute hand. Nine out of ten seconds, the only thing this routine is going to do other than set the second hand is check whether T[3] mod 10 is 0. This also saves some time and math because I don't have to check the angle of the graphics anymore. I just need to set it when the time is right. So no more mod 360. This is the same number of lines, but shorter and cleaner, I think. I could save two lines by adding an else to the if statements: if t[3] mod 10 <> 0 then exit setTime else set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) But that seems artificial and less clear than using two lines. Let me know what you think. regards, Geoff So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Plugins, tutorials and more on our website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I came up with a radically different approach. Several iterations ago, we realized that we didn't have to guess when it would be time to set the clock graphics. We could use 1-(the long seconds mod 1) to get a message sent exactly when we need it. Well, we're still guessing at when it's time to move the minute hand or the hour hand, and we don't need to. The minute hand moves one degree every ten seconds, the hour hand one degree every two minutes. The tests to determine this are simple. The natural thing to do is set the second hand, check to see if the minute hand needs to be set, and if it does check to see if the hour hand needs to be set. At each step, I want to exit if appropriate. The stumbling block was the send...in. I need to get to the end to do it. Then I realized -- the send...in doesn't have to be the last step. It can come at any point. So here's the script now: on openCard setTime end openCard on setTime send "setTime" to me in 1 - (the long seconds mod 1) seconds put word 1 of the long time into T --8:13:15 put T & char 2 to 7 of (the long seconds mod 1) into fld "Time" split T using ":" set the angle of grc "Second" to 450 - (6 * T[3]) if T[3] mod 10 <> 0 then exit setTime set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) if T[3] <> 0 or T[2] mod 2 <> 0 then exit setTime set the angle of grc "Hour" to 90 - (30 * T[1]) - (T[2] div 2) end setTime Notice how simple the check is for the minute hand. Nine out of ten seconds, the only thing this routine is going to do other than set the second hand is check whether T[3] mod 10 is 0. This also saves some time and math because I don't have to check the angle of the graphics anymore. I just need to set it when the time is right. So no more mod 360. This is the same number of lines, but shorter and cleaner, I think. I could save two lines by adding an else to the if statements: if t[3] mod 10 <> 0 then exit setTime else set the angle of grc "Minute" to 90 - (6 * T[2]) - (T[3] div 10) But that seems artificial and less clear than using two lines. Let me know what you think. regards, Geoff On Jun 7, 2005, at 9:01 AM, Dennis Brown wrote: Dar pointed out that this clock does not have a graceful stop. I changed the clock in my user space (see3d) to shut down the clock when the card is closed. Dennis On Jun 7, 2005, at 12:40 AM, Geoff Canyon wrote: I've posted the new revision: on openCard setTime end openCard on setTime put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" split T using ":" get (450 - (30 * T[1]) - (T[2] div 2)) mod 360 if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get (450 - (6 * T[2]) - (T[3] div 10)) mod 360 if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 450 - (6 * T[3]) send "setTime" to me in 1 - (the long seconds mod 1) seconds end setTime On Jun 6, 2005, at 9:38 AM, Dennis Brown wrote: Good catch. As was pointed out before, trunc(T[2] / 2) can be simplified to (T [2] div 2) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Dar pointed out that this clock does not have a graceful stop. I changed the clock in my user space (see3d) to shut down the clock when the card is closed. Dennis On Jun 7, 2005, at 12:40 AM, Geoff Canyon wrote: I've posted the new revision: on openCard setTime end openCard on setTime put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" split T using ":" get (450 - (30 * T[1]) - (T[2] div 2)) mod 360 if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get (450 - (6 * T[2]) - (T[3] div 10)) mod 360 if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 450 - (6 * T[3]) send "setTime" to me in 1 - (the long seconds mod 1) seconds end setTime On Jun 6, 2005, at 9:38 AM, Dennis Brown wrote: Good catch. As was pointed out before, trunc(T[2] / 2) can be simplified to (T [2] div 2) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I've posted the new revision: on openCard setTime end openCard on setTime put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" split T using ":" get (450 - (30 * T[1]) - (T[2] div 2)) mod 360 if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get (450 - (6 * T[2]) - (T[3] div 10)) mod 360 if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 450 - (6 * T[3]) send "setTime" to me in 1 - (the long seconds mod 1) seconds end setTime On Jun 6, 2005, at 9:38 AM, Dennis Brown wrote: Good catch. As was pointed out before, trunc(T[2] / 2) can be simplified to (T [2] div 2) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I missed that comment. Of course that's the case. I'm adding it in. On Jun 6, 2005, at 9:38 AM, Dennis Brown wrote: Good catch. As was pointed out before, trunc(T[2] / 2) can be simplified to (T [2] div 2) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Geoff, Good catch. As was pointed out before, trunc(T[2] / 2) can be simplified to (T[2] div 2) Dennis On Jun 6, 2005, at 11:45 AM, Geoff Canyon wrote: I've put up a summary of the refinement of this code at: http://www.inspiredlogic.com/beautiful/clockface.html I had to make a modification to the below "final" version, both to use the split command and because I realized that sometimes 450 - (30 * T[1]) - trunc(T[2] / 2) won't fall into the range 0-359. If it doesn't the value returned by the angle of the graphic the next time won't match (because it is always in 0-359) and so the hour hand's position will be set every second, which we're trying to avoid. The posted version is now: on openCard setTime end openCard on setTime put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" split T using ":" get (450 - (30 * T[1]) - trunc(T[2] / 2)) mod 360 if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get (450 - (6 * T[2]) - trunc(T[3] / 10)) mod 360 if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 360+90-(6 * item 3 of T) send "setTime" to me in 1-(the long seconds mod 1) seconds end setTime Let me know if you see an issue with that. gc On May 30, 2005, at 4:37 PM, Dennis Brown wrote: That is a good point. I tested it out, and the useless "set angle" results in about 70ms of wasted time every second (7% CPU). I am surprised it is so high. Doing the test and skipping it is a thousand times faster. I fixed up the script as my own exercise for the student. You can see the time lag slightly when the computer is busy with something else, like loading a web page. Note: the angle calculations had to be changed to match what the angle returned for these graphics. The clock is in my user space (see3d). It takes a licking, but keeps on ticking... on openCard setTime end openCard on setTime set the itemDelimiter to ":" put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" get 360+90-(30 * item 1 of T) - trunc((item 2 of T) / 2) if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get 360+90-(6 * item 2 of T) - trunc((item 3 of T) / 10) if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 360+90-(6 * item 3 of T) send "setTime" to me in 1-(the long seconds mod 1) seconds end setTime Dennis On May 30, 2005, at 2:21 PM, Geoff Canyon wrote: On May 30, 2005, at 10:04 AM, Dennis Brown wrote: Nice! I learn something every minute on this list --four heads are better than one. I do believe that the clock is down to its essence now. Every line does something essential, except displaying the "Time" field to check its accuracy. I put the latest version in my user space also (see3d). re: down to its essence -- obviously for this demo it doesn't matter, but in practice, I would want to put in code to only change the minute and hour hands when they actually need it, rather than setting them to the same startAngle (except when they actually move) each second. I haven't timed this to see whether it's actually a concern. And multiple heads are definitely better than one. That's why I plan to grow additional heads as soon as possible. ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I've put up a summary of the refinement of this code at: http://www.inspiredlogic.com/beautiful/clockface.html I had to make a modification to the below "final" version, both to use the split command and because I realized that sometimes 450 - (30 * T[1]) - trunc(T[2] / 2) won't fall into the range 0-359. If it doesn't the value returned by the angle of the graphic the next time won't match (because it is always in 0-359) and so the hour hand's position will be set every second, which we're trying to avoid. The posted version is now: on openCard setTime end openCard on setTime put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" split T using ":" get (450 - (30 * T[1]) - trunc(T[2] / 2)) mod 360 if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get (450 - (6 * T[2]) - trunc(T[3] / 10)) mod 360 if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 360+90-(6 * item 3 of T) send "setTime" to me in 1-(the long seconds mod 1) seconds end setTime Let me know if you see an issue with that. gc On May 30, 2005, at 4:37 PM, Dennis Brown wrote: That is a good point. I tested it out, and the useless "set angle" results in about 70ms of wasted time every second (7% CPU). I am surprised it is so high. Doing the test and skipping it is a thousand times faster. I fixed up the script as my own exercise for the student. You can see the time lag slightly when the computer is busy with something else, like loading a web page. Note: the angle calculations had to be changed to match what the angle returned for these graphics. The clock is in my user space (see3d). It takes a licking, but keeps on ticking... on openCard setTime end openCard on setTime set the itemDelimiter to ":" put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" get 360+90-(30 * item 1 of T) - trunc((item 2 of T) / 2) if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get 360+90-(6 * item 2 of T) - trunc((item 3 of T) / 10) if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 360+90-(6 * item 3 of T) send "setTime" to me in 1-(the long seconds mod 1) seconds end setTime Dennis On May 30, 2005, at 2:21 PM, Geoff Canyon wrote: On May 30, 2005, at 10:04 AM, Dennis Brown wrote: Nice! I learn something every minute on this list --four heads are better than one. I do believe that the clock is down to its essence now. Every line does something essential, except displaying the "Time" field to check its accuracy. I put the latest version in my user space also (see3d). re: down to its essence -- obviously for this demo it doesn't matter, but in practice, I would want to put in code to only change the minute and hour hands when they actually need it, rather than setting them to the same startAngle (except when they actually move) each second. I haven't timed this to see whether it's actually a concern. And multiple heads are definitely better than one. That's why I plan to grow additional heads as soon as possible. ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Hi Dar, Agreed a thousand times. To pass code (we say that in french but not in english may be :-) may be very valuable (and I often admire) but it is not enough... Code is not a goal. It is only a means (often exciting). Our final goal is an application that suits the needs of our clients (or users) with a perfect (???) design, good ergonomics, 100% (???) reliability, etc. But I am not a programmer, I am a midwife ;-) Best regards from Paris, Eric Chatonet. Le 31 mai 05 à 18:51, Dar Scott a écrit : Concerning the "coded in 3 minutes" in the subject. I wouldn't want anybody to be intimidated by this. I'm an experienced programmer. My customers come back for more. Though others create in a different style, my design style might be a yardstick. I might code a similar solution in 3 minutes, maybe more. But--for me--that might be after a period on pondering options: ellipses at angle, images at angle, lines, single polygon, multiple polygons, overlapping animated gifs, rebuilding images And I might try some experiments or look at what others have done or see what images components are available and so on. I might consider issues such as stopping the thing. I might make some queries on this list. For me the coding is a small part of the design process. For one customer after a couple hours of research I coded up a solution in seconds and my customer was very happy. For some folks the script editor is where they explore ideas, allowing the structure of code to help ideas come together. They might write a few pieces that help in thinking about the rest. Code might move around. I don't think we can call these folks slow coders; they are using scripts to work with ideas. Others need time, they don't get their best ideas on demand. Some folks wake up in the morning with ideas or get them in the shower or in traffic. So, if making a clock takes hours staring at clocks or tinkering or chatting with others or whatever, that is OK. We have different styles and we are all learning and growing. Though there might be some who go from challenge to script in 3 minutes, for most of us mere mortals the total time to design is longer. Dar So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Plugins, tutorials and more on our website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I updated my clock and tested the cpu time again. I must have slipped a tick or something, because now I get 1.5% cpu with the simple script and 0.8% cpu with my time saving script. Much more like I though it should be. I am happy with either one, so I put both scripts in the clock in my user space. Dennis on openCard setTime2 --set to which script to run end openCard on setTime1 --this is the simplest script (1.5%) --put the long seconds into ST put word 1 of the long time into T --8:13:15 put T into fld "Time" --8:13:15.000 split T using ":" --make array of the 3 numbers set the angle of grc "Hour" to 360+90-(30*T[1]) - trunc(T[2]/2) -- angles in even degrees set the angle of grc "Minute" to 360+90-(6*T[2]) - trunc(T[3]/10) set the angle of grc "Second" to 360+90 - 6*T[3] send "setTime1" to me in 1-(the long seconds mod 1) seconds --time left to next second --put (((the long seconds)-ST)*100)&"% cpu" end setTime1 on setTime2 --this script uses less CPU time (0.8%) --put the long seconds into ST put word 1 of the long time into T --8:13:15 put T into fld "Time" --8:13:15.000 split T using ":" --make array of the 3 numbers get 360+90-(30*T[1]) - trunc(T[2]/2) --angle of the hour "hand" if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get 360+90-(6*T[2]) - trunc(T[3]/10) --angle of the minute "hand" if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 360+90 - 6*T[3] send "setTime2" to me in 1-(the long seconds mod 1) seconds --time left to next second --put (((the long seconds)-ST)*100)&"% cpu" end setTime2 On May 31, 2005, at 10:12 AM, Geoff Canyon wrote: On May 31, 2005, at 6:05 AM, Dennis Brown wrote: I can't say that I would make the tradeoff of the extra lines of code for a few microseconds, but I really like the split idea --it shows another concept in a simple way and makes the script look even simpler. I updated my clock with it. Good thinking! I agree that the tradeoff is of arguable benefit. Having to use local variables is another drawback in favor of just comparing to the startAngle. Using local variables is habit because I end up in this situation with text in a field much more often than with the startAngle of a graphic. Text in a field is much slower in comparison -- the startAngle is acceptably fast. Thanks re: the split command. I don't remember when that first occurred to me, but I was pretty pleased with myself that day too ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Concerning the "coded in 3 minutes" in the subject. I wouldn't want anybody to be intimidated by this. I'm an experienced programmer. My customers come back for more. Though others create in a different style, my design style might be a yardstick. I might code a similar solution in 3 minutes, maybe more. But--for me--that might be after a period on pondering options: ellipses at angle, images at angle, lines, single polygon, multiple polygons, overlapping animated gifs, rebuilding images And I might try some experiments or look at what others have done or see what images components are available and so on. I might consider issues such as stopping the thing. I might make some queries on this list. For me the coding is a small part of the design process. For one customer after a couple hours of research I coded up a solution in seconds and my customer was very happy. For some folks the script editor is where they explore ideas, allowing the structure of code to help ideas come together. They might write a few pieces that help in thinking about the rest. Code might move around. I don't think we can call these folks slow coders; they are using scripts to work with ideas. Others need time, they don't get their best ideas on demand. Some folks wake up in the morning with ideas or get them in the shower or in traffic. So, if making a clock takes hours staring at clocks or tinkering or chatting with others or whatever, that is OK. We have different styles and we are all learning and growing. Though there might be some who go from challenge to script in 3 minutes, for most of us mere mortals the total time to design is longer. Dar -- ** DSC (Dar Scott Consulting & Dar's Lab) http://www.swcp.com/dsc/ A sponsor of RevCon West '05 ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Geoff- Monday, May 30, 2005, 9:55:48 PM, you wrote: GC> Darn, forgot one more thing. Instead of setting the itemDelimiter, GC> using the split command allows a cleaner T[1] syntax instead of item GC> 1 of T. It is probably a bit faster as well. Thanks for the example. I never think about the split command - maybe this will get me to bring it to mind more often. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 31, 2005, at 6:05 AM, Dennis Brown wrote: I can't say that I would make the tradeoff of the extra lines of code for a few microseconds, but I really like the split idea --it shows another concept in a simple way and makes the script look even simpler. I updated my clock with it. Good thinking! I agree that the tradeoff is of arguable benefit. Having to use local variables is another drawback in favor of just comparing to the startAngle. Using local variables is habit because I end up in this situation with text in a field much more often than with the startAngle of a graphic. Text in a field is much slower in comparison -- the startAngle is acceptably fast. Thanks re: the split command. I don't remember when that first occurred to me, but I was pretty pleased with myself that day too ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I like that "split" concept. I am always setting itemdelimiter to odd
characters and then depending on it to reset itself and sometimes getting
caught.
On 5/31/05 12:55 AM, "Geoff Canyon" <[EMAIL PROTECTED]> wrote:
> Darn, forgot one more thing. Instead of setting the itemDelimiter,
> using the split command allows a cleaner T[1] syntax instead of item
> 1 of T. It is probably a bit faster as well.
>
> New script:
>
> on openCard
>setTime
> end openCard
>
> local sHourAngle -- the angle for the hour hand
> local sMinuteAngle -- the angle for the minute hand
>
> on setTime
>put word 1 of the long time into T
>put T && the long seconds into fld "time"
>split T using ":"
>get 90 - (30 * T[1]) - trunc(T[2] / 2)
>if it is not sHourAngle then
> put it into sHourAngle
> set the startangle of grc "hour" to sHourAngle
>end if
>get 90 - (6 * T[2]) - trunc(T[3] / 10)
>if it is not sMinuteAngle then
> put it into sMinuteAngle
> set the startangle of grc "minute" to sMinuteAngle
>end if
>set the startangle of grc "second" to 90 - (6 * T[3])
>send "setTime" to me in (1 - (the long seconds mod 1)) seconds
> end setTime
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
|||
)_) )_) )_)
)___))___))___)\
)))_)\\
_|||\\\__
---\ /- http://www.bluewatermaritime.com
^ ^
^^^^^
^^^
24 hour cell: (787) 378-6190
fax: (787) 809-8426
Blue Water Maritime
P.O. Box 91
Puerto Real, PR 00740
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I can't say that I would make the tradeoff of the extra lines of code for a few microseconds, but I really like the split idea --it shows another concept in a simple way and makes the script look even simpler. I updated my clock with it. Good thinking! Dennis On May 31, 2005, at 12:55 AM, Geoff Canyon wrote: Darn, forgot one more thing. Instead of setting the itemDelimiter, using the split command allows a cleaner T[1] syntax instead of item 1 of T. It is probably a bit faster as well. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Ummm... beep's working just fine here (Rev 2.5B1, Mac OS 10.3.8). Judy On Mon, 30 May 2005, Thomas McGrath III wrote: > I have not been able to get REV on the MAC to Beep. Can anyone else get > the beep to work? ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Darn, forgot one more thing. Instead of setting the itemDelimiter, using the split command allows a cleaner T[1] syntax instead of item 1 of T. It is probably a bit faster as well. New script: on openCard setTime end openCard local sHourAngle -- the angle for the hour hand local sMinuteAngle -- the angle for the minute hand on setTime put word 1 of the long time into T put T && the long seconds into fld "time" split T using ":" get 90 - (30 * T[1]) - trunc(T[2] / 2) if it is not sHourAngle then put it into sHourAngle set the startangle of grc "hour" to sHourAngle end if get 90 - (6 * T[2]) - trunc(T[3] / 10) if it is not sMinuteAngle then put it into sMinuteAngle set the startangle of grc "minute" to sMinuteAngle end if set the startangle of grc "second" to 90 - (6 * T[3]) send "setTime" to me in (1 - (the long seconds mod 1)) seconds end setTime ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 30, 2005, at 4:37 PM, Dennis Brown wrote: That is a good point. I tested it out, and the useless "set angle" results in about 70ms of wasted time every second (7% CPU). I am surprised it is so high. Doing the test and skipping it is a thousand times faster. I fixed up the script as my own exercise for the student. You can see the time lag slightly when the computer is busy with something else, like loading a web page. Note: the angle calculations had to be changed to match what the angle returned for these graphics. The clock is in my user space (see3d). It takes a licking, but keeps on ticking... Four times faster still is comparing to a local variable rather than to the startAngle of the graphics. It adds a few lines of code though. It would appear that my web hosting company is down at the moment, so the script will have to suffice: on openCard setTime end openCard local sHourAngle -- the angle for the hour hand local sMinuteAngle -- the angle for the minute hand on setTime put word 1 of the long time into T put T && the long seconds into fld "time" set the itemDelimiter to ":" get 90 - (30 * item 1 of T) - trunc((item 2 of T) / 2) if it is not sHourAngle then put it into sHourAngle set the startangle of grc "hour" to sHourAngle end if get 90 - (6 * item 2 of T) - trunc((item 3 of T) / 10) if it is not sMinuteAngle then put it into sMinuteAngle set the startangle of grc "minute" to sMinuteAngle end if set the startangle of grc "second" to 90 - (6 * item 3 of T) send "setTime" to me in (1 - (the long seconds mod 1)) seconds end setTime ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I went looking and although the system beeps and sound works the sound pane in OSX had no item selected for system beeps. That is very odd. I wonder how that could get changed. Aside from me doing it of course. Beeps are fine now, Thanks Björnke Tom On May 30, 2005, at 7:57 PM, Björnke von Gierke wrote: On May 31 2005, at 01:44, Thomas McGrath III wrote: I have not been able to get REV on the MAC to Beep. Can anyone else get the beep to work? 1. check if you get sound from other apps, and that you have actually a sound allocated for beeping 2. the command to do a beep is "beep", try it in the message box if these two conditions are met then you might want to try it on another mac (if possible) it should really beep, so maybe it's a bug? -- official ChatRev page: http://chatrev.cjb.net Chat with other RunRev developers: go stack URL "http://homepage.mac.com/bvg/chatrev1.3.rev"; ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution Thomas J. McGrath III SCS 1000 Killarney Dr. Pittsburgh, PA 15234 412-885-8541 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 31 2005, at 01:44, Thomas McGrath III wrote: I have not been able to get REV on the MAC to Beep. Can anyone else get the beep to work? 1. check if you get sound from other apps, and that you have actually a sound allocated for beeping 2. the command to do a beep is "beep", try it in the message box if these two conditions are met then you might want to try it on another mac (if possible) it should really beep, so maybe it's a bug? -- official ChatRev page: http://chatrev.cjb.net Chat with other RunRev developers: go stack URL "http://homepage.mac.com/bvg/chatrev1.3.rev"; ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I have not been able to get REV on the MAC to Beep. Can anyone else get the beep to work? Thanks Tom On May 30, 2005, at 1:04 PM, Dennis Brown wrote: Nice! I learn something every minute on this list --four heads are better than one. I do believe that the clock is down to its essence now. Every line does something essential, except displaying the "Time" field to check its accuracy. I put the latest version in my user space also (see3d). For the next exercise: Students (Ben) should use the principles learned here to make the clock chime (beep) the hour on the hour one second between chimes (better add a checkmark button to turn off chimes -- if you want to keep your sanity). Dennis On May 30, 2005, at 12:22 PM, Geoff Canyon wrote: I had just finished swapping out my clunky send...in loop code for something similar to yours when I checked mail and saw yours. I took two steps: put the long seconds into t send in (something based on t - trunc(t) Your method of the long seconds mod 1 is of course much better. But you don't have to convert to ticks. Sending in a fraction of a second works fine and reads better imho. So here's what I have up now. This generally hits within a thousandth of a second: on openCard setTime end openCard on setTime put word 1 of the long time into T put T && the long seconds into fld "time" set the itemDelimiter to ":" set the startangle of grc "hour" to 90 - (30 * item 1 of T) - (item 2 of T) / 2 set the startangle of grc "minute" to 90 - (6 * item 2 of T) - (item 3 of T) / 10 set the startangle of grc "second" to 90 - (6 * item 3 of T) send "setTime" to me in (1 - (the long seconds mod 1)) seconds end setTime As before, the stack is available by executing this in the message box: go stack url "http://www.inspiredlogic.com/rev/clock.rev"; On May 30, 2005, at 9:01 AM, Dennis Brown wrote: I love this clock example. Just so simple. You guys are great! I could not resist seeing how the thinking was progressing and took it to the next step. Fewer lines, more accuracy (I have often noted that the simplest most elegant solutions take the most time to create and the least time to understand). As Ben suggested, this clock should be a standard example for new users to look at. I will also add it to my revOnline user area (see3d) as soon as today's connect problem is fixed. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution Thomas J. McGrath III SCS 1000 Killarney Dr. Pittsburgh, PA 15234 412-885-8541 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
That is a good point. I tested it out, and the useless "set angle" results in about 70ms of wasted time every second (7% CPU). I am surprised it is so high. Doing the test and skipping it is a thousand times faster. I fixed up the script as my own exercise for the student. You can see the time lag slightly when the computer is busy with something else, like loading a web page. Note: the angle calculations had to be changed to match what the angle returned for these graphics. The clock is in my user space (see3d). It takes a licking, but keeps on ticking... on openCard setTime end openCard on setTime set the itemDelimiter to ":" put word 1 of the long time into T --8:13:15 put T & char 2 to 5 of (the long seconds mod 1) into fld "Time" get 360+90-(30 * item 1 of T) - trunc((item 2 of T) / 2) if (the angle of grc "Hour") <> it then set the angle of grc "Hour" to it get 360+90-(6 * item 2 of T) - trunc((item 3 of T) / 10) if (the angle of grc "Minute") <> it then set the angle of grc "Minute" to it set the angle of grc "Second" to 360+90-(6 * item 3 of T) send "setTime" to me in 1-(the long seconds mod 1) seconds end setTime Dennis On May 30, 2005, at 2:21 PM, Geoff Canyon wrote: On May 30, 2005, at 10:04 AM, Dennis Brown wrote: Nice! I learn something every minute on this list --four heads are better than one. I do believe that the clock is down to its essence now. Every line does something essential, except displaying the "Time" field to check its accuracy. I put the latest version in my user space also (see3d). re: down to its essence -- obviously for this demo it doesn't matter, but in practice, I would want to put in code to only change the minute and hour hands when they actually need it, rather than setting them to the same startAngle (except when they actually move) each second. I haven't timed this to see whether it's actually a concern. And multiple heads are definitely better than one. That's why I plan to grow additional heads as soon as possible. ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 30, 2005, at 12:18 PM, Geoff Canyon wrote: I considered that possibility as well, but in practice it seems not. I think we thought of this because we're both being worrywarts. The math should result in, at minimum, a wait to _exactly_ the next second. If that happens _and_ the time spent executing the send...in is 0, _and_ the send...in trigger happens _exactly_ on schedule, it would still be he next second, and do the right thing. Underneath, the queued message is associated with a time. In my tests, that time is just past the whole second. Perhaps the code that checks the pending messages waits to see if the current time is greater than or equal the time associated with the message. So, even if the clock has a low resolution, it has to pass the target time. Also, the time value used in display is probably based on the same clock, so all is well. Dar -- ** DSC (Dar Scott Consulting & Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 30, 2005, at 10:04 AM, Dennis Brown wrote: Nice! I learn something every minute on this list --four heads are better than one. I do believe that the clock is down to its essence now. Every line does something essential, except displaying the "Time" field to check its accuracy. I put the latest version in my user space also (see3d). re: down to its essence -- obviously for this demo it doesn't matter, but in practice, I would want to put in code to only change the minute and hour hands when they actually need it, rather than setting them to the same startAngle (except when they actually move) each second. I haven't timed this to see whether it's actually a concern. And multiple heads are definitely better than one. That's why I plan to grow additional heads as soon as possible. ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 30, 2005, at 9:43 AM, Dar Scott wrote: On May 30, 2005, at 10:22 AM, Geoff Canyon wrote: send "setTime" to me in (1 - (the long seconds mod 1)) seconds Very nice. If I ever get around to updating the Primer on Message Mechanics, this should go in there. At first I thought this might need a little fudge value added, but now I think not. I considered that possibility as well, but in practice it seems not. I think we thought of this because we're both being worrywarts. The math should result in, at minimum, a wait to _exactly_ the next second. If that happens _and_ the time spent executing the send...in is 0, _and_ the send...in trigger happens _exactly_ on schedule, it would still be he next second, and do the right thing. Of course, nothing beats _not_ putting in the fudge factor and watching it for a minute to see what happens, which is what I did. ;-) ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Nice! I learn something every minute on this list --four heads are better than one. I do believe that the clock is down to its essence now. Every line does something essential, except displaying the "Time" field to check its accuracy. I put the latest version in my user space also (see3d). For the next exercise: Students (Ben) should use the principles learned here to make the clock chime (beep) the hour on the hour one second between chimes (better add a checkmark button to turn off chimes -- if you want to keep your sanity). Dennis On May 30, 2005, at 12:22 PM, Geoff Canyon wrote: I had just finished swapping out my clunky send...in loop code for something similar to yours when I checked mail and saw yours. I took two steps: put the long seconds into t send in (something based on t - trunc(t) Your method of the long seconds mod 1 is of course much better. But you don't have to convert to ticks. Sending in a fraction of a second works fine and reads better imho. So here's what I have up now. This generally hits within a thousandth of a second: on openCard setTime end openCard on setTime put word 1 of the long time into T put T && the long seconds into fld "time" set the itemDelimiter to ":" set the startangle of grc "hour" to 90 - (30 * item 1 of T) - (item 2 of T) / 2 set the startangle of grc "minute" to 90 - (6 * item 2 of T) - (item 3 of T) / 10 set the startangle of grc "second" to 90 - (6 * item 3 of T) send "setTime" to me in (1 - (the long seconds mod 1)) seconds end setTime As before, the stack is available by executing this in the message box: go stack url "http://www.inspiredlogic.com/rev/clock.rev"; On May 30, 2005, at 9:01 AM, Dennis Brown wrote: I love this clock example. Just so simple. You guys are great! I could not resist seeing how the thinking was progressing and took it to the next step. Fewer lines, more accuracy (I have often noted that the simplest most elegant solutions take the most time to create and the least time to understand). As Ben suggested, this clock should be a standard example for new users to look at. I will also add it to my revOnline user area (see3d) as soon as today's connect problem is fixed. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On May 30, 2005, at 10:22 AM, Geoff Canyon wrote: send "setTime" to me in (1 - (the long seconds mod 1)) seconds Very nice. If I ever get around to updating the Primer on Message Mechanics, this should go in there. At first I thought this might need a little fudge value added, but now I think not. Dar -- ** DSC (Dar Scott Consulting & Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I had just finished swapping out my clunky send...in loop code for something similar to yours when I checked mail and saw yours. I took two steps: put the long seconds into t send in (something based on t - trunc(t) Your method of the long seconds mod 1 is of course much better. But you don't have to convert to ticks. Sending in a fraction of a second works fine and reads better imho. So here's what I have up now. This generally hits within a thousandth of a second: on openCard setTime end openCard on setTime put word 1 of the long time into T put T && the long seconds into fld "time" set the itemDelimiter to ":" set the startangle of grc "hour" to 90 - (30 * item 1 of T) - (item 2 of T) / 2 set the startangle of grc "minute" to 90 - (6 * item 2 of T) - (item 3 of T) / 10 set the startangle of grc "second" to 90 - (6 * item 3 of T) send "setTime" to me in (1 - (the long seconds mod 1)) seconds end setTime As before, the stack is available by executing this in the message box: go stack url "http://www.inspiredlogic.com/rev/clock.rev"; On May 30, 2005, at 9:01 AM, Dennis Brown wrote: I love this clock example. Just so simple. You guys are great! I could not resist seeing how the thinking was progressing and took it to the next step. Fewer lines, more accuracy (I have often noted that the simplest most elegant solutions take the most time to create and the least time to understand). As Ben suggested, this clock should be a standard example for new users to look at. I will also add it to my revOnline user area (see3d) as soon as today's connect problem is fixed. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I love this clock example. Just so simple. You guys are great! I could not resist seeing how the thinking was progressing and took it to the next step. Fewer lines, more accuracy (I have often noted that the simplest most elegant solutions take the most time to create and the least time to understand). As Ben suggested, this clock should be a standard example for new users to look at. I will also add it to my revOnline user area (see3d) as soon as today's connect problem is fixed. on openCard setTime end openCard on setTime set the itemDelimiter to ":" get word 1 of the long time --8:13:15 put it & char 2 to 5 of (the long seconds mod 1) into fld "Time" set the startangle of grc "hour" to 90 - (30 * item 1 of it) - (item 2 of it) / 2 set the startangle of grc "minute" to 90 - (6 * item 2 of it) - (item 3 of it) / 10 set the startangle of grc "second" to 90 - (6 * item 3 of it) send "setTime" to me in 60-(the long seconds mod 1)*60 ticks end setTime Dennis - On May 30, 2005, at 3:03 AM, Geoff Canyon wrote: I originally went with polygon graphics, which put me at about twenty lines of code by your way of counting (including "on" and "end" statements). Switching to oval graphics I got it down to 11 lines, which sweep both the hour and minute hands. But the second hand is jumpy. Simply using send...in just about always results in the second hand either taking noticeably too long or too short to measure a second here or there. So I added code to time seconds more finely. This results in the second hand always ticking when it's supposed to. The display shows the long seconds, and you can watch the updates hit consistently in the first tenth of a second or so. It puts me up at 18 lines of code, but the result is worth it I think: on openCard setTime end openCard local sTime on setTime put word 1 of the long time into tTime if tTime is sTime then send "setTime" to me in 5 ticks exit setTime end if put tTime into sTime put sTime && the long seconds into fld "time" set the itemDelimiter to ":" set the startangle of grc "hour" to 90 - (30 * item 1 of sTime) - (item 2 of sTime) / 2 set the startangle of grc "minute" to 90 - (6 * item 2 of sTime) - (item 3 of sTime) / 10 set the startangle of grc "second" to 90 - (6 * item 3 of sTime) send "setTime" to me in 50 ticks end setTime The stack is available by executing this in the message box: go stack url "http://www.inspiredlogic.com/rev/clock.rev"; On May 27, 2005, at 4:08 PM, Malte Brill wrote: Sorry, couldn´t resist on mouseUp if the flag of me is empty then set the flag of me to false set the flag of me to not the flag of me if the flag of me then startClock end mouseUp on startclock put the long time into myTime put myTime into fld 1 set the itemdel to ":" put char 1 to 2 of item 3 of myTime into daSecs set the startAngle of grc "seconds" to 90-dasecs*6 put item 2 of myTime into daMinutes set the startangle of grc minutes to 90-daminutes*6 put item 1 of myTime into daHours set the startAngle of grc "hours" to 90-dahours*30-daminutes*30/60 if the flag of me then send startClock to me in 500 milliseconds end startclock Cheers, Malte Create 3 oval graphics set arcangle of each graphic to zero loc of all 3 needs to be the same 1 field to put the time in Cheers, Malte ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Hi all, I wouldn´t have expected so many reactions on the short script I postet. Thanks for the feedback.I should have taken the time to read through the code before posting it and clean it up a bit, though.(You are right DOM, I forgot the quotes around the name of the graphic) And I would have checked every 50 milliseconds instead of 500... :-) Geoff, your changes are excellent. Very clean! I really like it. Actually it was late that night when I tested how fast I could set up a clock and I felt like screaming in the subject after reading a bit in the archives. Never mind. Dom wrote: >now, what about making a rounded window, with the time and the date? Go for it! I would like to see it. Cheers, Malte ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Geoff Canyon <[EMAIL PROTECTED]> wrote: > go stack url "http://www.inspiredlogic.com/rev/clock.rev"; nice one, too! now, what about making a rounded window, with the time and the date? -- Revolutionario ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
I originally went with polygon graphics, which put me at about twenty lines of code by your way of counting (including "on" and "end" statements). Switching to oval graphics I got it down to 11 lines, which sweep both the hour and minute hands. But the second hand is jumpy. Simply using send...in just about always results in the second hand either taking noticeably too long or too short to measure a second here or there. So I added code to time seconds more finely. This results in the second hand always ticking when it's supposed to. The display shows the long seconds, and you can watch the updates hit consistently in the first tenth of a second or so. It puts me up at 18 lines of code, but the result is worth it I think: on openCard setTime end openCard local sTime on setTime put word 1 of the long time into tTime if tTime is sTime then send "setTime" to me in 5 ticks exit setTime end if put tTime into sTime put sTime && the long seconds into fld "time" set the itemDelimiter to ":" set the startangle of grc "hour" to 90 - (30 * item 1 of sTime) - (item 2 of sTime) / 2 set the startangle of grc "minute" to 90 - (6 * item 2 of sTime) - (item 3 of sTime) / 10 set the startangle of grc "second" to 90 - (6 * item 3 of sTime) send "setTime" to me in 50 ticks end setTime The stack is available by executing this in the message box: go stack url "http://www.inspiredlogic.com/rev/clock.rev"; On May 27, 2005, at 4:08 PM, Malte Brill wrote: Sorry, couldn´t resist on mouseUp if the flag of me is empty then set the flag of me to false set the flag of me to not the flag of me if the flag of me then startClock end mouseUp on startclock put the long time into myTime put myTime into fld 1 set the itemdel to ":" put char 1 to 2 of item 3 of myTime into daSecs set the startAngle of grc "seconds" to 90-dasecs*6 put item 2 of myTime into daMinutes set the startangle of grc minutes to 90-daminutes*6 put item 1 of myTime into daHours set the startAngle of grc "hours" to 90-dahours*30-daminutes*30/60 if the flag of me then send startClock to me in 500 milliseconds end startclock Cheers, Malte Create 3 oval graphics set arcangle of each graphic to zero loc of all 3 needs to be the same 1 field to put the time in Cheers, Malte ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
On 5/27/05, Malte Brill <[EMAIL PROTECTED]> wrote: > Sorry, couldn't resist > Hey Malte, This is so brilliant! I love it. I tweaked its visuals a little (made the second hand a different color, fattened and shortened the hour hand, etc.) and built it as a standalone. It now runs on my desktop. What a great example of a useful, potentially complex program reduced to its essence with Revolution. -- Regards, Howard Bornstein --- www.designeq.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
Malte Brill <[EMAIL PROTECTED]> wrote: > Sorry, couldn´t resist Faites, cher ami :-) Brilliant, indeed, sort of "Rev widget"! (need to quote the "minutes" litteral and, perhaps, to declare local dasecs,daminutes,dahours) -- Revolutionario ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
you didn't even try to do it yourself You just looked at someone else's code and decided it must all be that way? Then HOW WOULD YOU KNOW QUALITY TRANSCRIPT at all On May 27, 2005, at 8:47 PM, [EMAIL PROTECTED] wrote: that seams like QUALITY TRANSCRIPT the clock face i looked at was 100 lines of code...and awfull ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
[EMAIL PROTECTED] wrote: that seams like QUALITY TRANSCRIPT the clock face i looked at was 100 lines of code...and awfull you must be GOOD at transcript ...to do this clock...in 3 minutes.VERY GOOD INDEED... Malte as a true master. You should see the games he demo'd at the Euro RevCon in Malta last November -- his Transcript is very worth learning from. still, it does NOT helpwhen the REV tutorials about TRanscript are so BAD... What parts of them didn't work out for you? What would you prefer to see? -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: here is the CLOCKFACE script...coded in 3 MINUTES...17 LINES of CODE
yes that seams like QUALITY TRANSCRIPT the clock face i looked at was 100 lines of code...and awfull you must be GOOD at transcript ...to do this clock...in 3 minutes.VERY GOOD INDEED... it would take meDAYS to achieve this still, it does NOT helpwhen the REV tutorials about TRanscript are so BAD... hopefully this LESSON tomorrow...will help... they need to cover the PRINCIPLES of OBJECT ORIENTATED programming...this is what is missig from the REV web site tutorials... cheers Ben ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
