On Fri, 22 Jun 2007, Enrique Erne wrote:
On Jun 22, 2007, at 6:54 PM, Roman Haefeli wrote:
lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. won't be hit at all. then i think, that this approach wouldn't be accurate at all, since there is no logical time involved. the advantage of logical time is,
i think your totally right... too bad.
Then both of you need to read the helpfile of [timer] and compare it with the one of [realtime]: [timer] works in logical time only.
If you want to make a [realmetro] abstraction, you use [realtime] to figure out whether you are late, and in the case you figure out that you are too late, you bang to the right outlet of your [realmetro], so that the user can bang some kind of catch-up routine in order to skip a frame while keeping everything else in sync with the logical time.
In no case, [realmetro] will ever be in advance, except to the extent that buffering happens in order to smooth out the irregularities in the schedule (afaik this only happens for audio). It may look in advance if even the first bang of a given [metro] was late and you assumed that it wasn't.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Sat, 2007-06-23 at 06:59 -0400, Mathieu Bouchard wrote:
On Fri, 22 Jun 2007, Enrique Erne wrote:
On Jun 22, 2007, at 6:54 PM, Roman Haefeli wrote:
lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. won't be hit at all. then i think, that this approach wouldn't be accurate at all, since there is no logical time involved. the advantage of logical time is,
i think your totally right... too bad.
Then both of you need to read the helpfile of [timer] and compare it with the one of [realtime]: [timer] works in logical time only.
oops, i meant to talk about a solution based on zexy's [time], not on [timer] (typo). however, since there is [realtime], it wouldn't make much sense to use [timer]. you could reach the same with both.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli a écrit :
On Sat, 2007-06-23 at 06:59 -0400, Mathieu Bouchard wrote:
On Fri, 22 Jun 2007, Enrique Erne wrote:
On Jun 22, 2007, at 6:54 PM, Roman Haefeli wrote:
lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. won't be hit at all. then i think, that this approach wouldn't be accurate at all, since there is no logical time involved. the advantage of logical time is,
i think your totally right... too bad.
Then both of you need to read the helpfile of [timer] and compare it with the one of [realtime]: [timer] works in logical time only.
oops, i meant to talk about a solution based on zexy's [time], not on [timer] (typo). however, since there is [realtime], it wouldn't make much sense to use [timer]. you could reach the same with both.
roman
following the doc it is clear that there is a big difference between [timer] and [realtime], I don't understand what is the meaning of 'same with both' in your sentence. If the 'universal space-time continuum' model makes sense, only the acceleration of motion between the computers running the Real Time metronome could shift the counting.
i think he means you could reach the same result using [realtime] or zexy's [time]
....and i would add that you could possibly even get the same using the [timer] object connected to an [einstein-rosen_bridge] external
hard off a écrit :
i think he means you could reach the same result using [realtime] or zexy's [time]
....and i would add that you could possibly even get the same using the [timer] object connected to an [einstein-rosen_bridge] external
wormholes are fiction
On Sun, 2007-06-24 at 18:16 +0200, Patco wrote:
Roman Haefeli a écrit :
On Sat, 2007-06-23 at 06:59 -0400, Mathieu Bouchard wrote:
On Fri, 22 Jun 2007, Enrique Erne wrote:
On Jun 22, 2007, at 6:54 PM, Roman Haefeli wrote:
lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. won't be hit at all. then i think, that this approach wouldn't be accurate at all, since there is no logical time involved. the advantage of logical time is,
i think your totally right... too bad.
Then both of you need to read the helpfile of [timer] and compare it with the one of [realtime]: [timer] works in logical time only.
oops, i meant to talk about a solution based on zexy's [time], not on [timer] (typo). however, since there is [realtime], it wouldn't make much sense to use [timer]. you could reach the same with both.
roman
following the doc it is clear that there is a big difference between [timer] and [realtime], I don't understand what is the meaning of 'same with both' in your sentence. If the 'universal space-time continuum' model makes sense, only the acceleration of motion between the computers running the Real Time metronome could shift the counting.
i meant: both are realtime based and both need to be triggered in order to give you a result. in order to create a 'drop-out safe metro', you would have to 'bang' them with some very high (whatever that means) rate.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sun, 24 Jun 2007, Roman Haefeli wrote:
On Sat, 2007-06-23 at 06:59 -0400, Mathieu Bouchard wrote:
Then both of you need to read the helpfile of [timer] and compare it with the one of [realtime]: [timer] works in logical time only.
oops, i meant to talk about a solution based on zexy's [time], not on [timer] (typo). however, since there is [realtime], it wouldn't make much sense to use [timer]. you could reach the same with both.
[timer] wouldn't make sense because when triggered with a metro it'll always give you the exact value that you've already told [metro] to use, and nothing else. I mean, it's completely useless.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
hard off -
Mathieu Bouchard -
Patco -
Roman Haefeli