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
the implementation is quite simple. see attached patch. (though it
requires two instances of pd, that are connected somehow over a digital
audio connection, e.g jack)
roman
On Fri, 2007-06-22 at 19:52 +0200, Roman Haefeli wrote:
On Fri, 2007-06-22 at 19:40 +0200, Roman Haefeli wrote:
On Fri,
On Mon, 25 Jun 2007, roman wrote:
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.
following the doc it is clear that there is a big
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
On Mon, 2007-06-25 at 14:43 -0400, Mathieu Bouchard wrote:
On Mon, 25 Jun 2007, roman wrote:
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
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
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
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
http://en.wikipedia.org/wiki/Wormhole
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
http://en.wikipedia.org/wiki/Wormhole
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
hi
has anybody built a dropout save metro ... say if pd freezes for a
while and comes back that the metro would still be in sync with the
'outside' world. that would be very nice in a life situation.
some ideas ? do you think it can be done in plain pd?
i failed when i tried to measure the
I have thought about making a 'real time' metro. One of the features
I was considering was what to do if the event happens too late, would
the output fire or drop the event?
On 6/22/07, Enrique Erne [EMAIL PROTECTED] wrote:
hi
has anybody built a dropout save metro ... say if pd freezes for a
the problem with timer is, that it only sends an output, when banged.
you could bang it with some insane rate using a [metro 1000] and
according to the measured (real)time, you send a bang or not.
this approach would *might* work, but it has several disadvantages, if i
do understand the
if the event(s) happen to late i.e after a dropout i wouldn't want it
to trigger anything.
but on the other hand: i would anyway use it for a counter... then i
wanted it to count further. if it counts from 1 to 4 and misses the 2th
event it should go to 3 on the next supposed event to be in
Hallo,
Enrique Erne hat gesagt: // Enrique Erne wrote:
has anybody built a dropout save metro ... say if pd freezes for a
while and comes back that the metro would still be in sync with the
'outside' world. that would be very nice in a life situation.
some ideas ? do you think it can be
one solution, that might would work, came to my mind. you could run two
instances of pd, one does only hold a [metro] and has a slightly higher
priority than the other instance. the second pd does all the audio stuff
and therefore might have some dropouts. now you could send the output of
the
On Fri, 2007-06-22 at 19:22 +0200, Roman Haefeli wrote:
one solution, that might would work, came to my mind. you could run two
instances of pd, one does only hold a [metro] and has a slightly higher
priority than the other instance. the second pd does all the audio stuff
and therefore might
On Fri, 2007-06-22 at 19:40 +0200, Roman Haefeli wrote:
On Fri, 2007-06-22 at 19:22 +0200, Roman Haefeli wrote:
one solution, that might would work, came to my mind. you could run two
instances of pd, one does only hold a [metro] and has a slightly higher
priority than the other instance.
i think your totally right... too bad.
On Jun 22, 2007, at 6:54 PM, Roman Haefeli wrote:
the problem with timer is, that it only sends an output, when banged.
you could bang it with some insane rate using a [metro 1000] and
according to the measured (real)time, you send a bang or not.
this
yeah that sounds like nice solution.
and a reason to install jack .
thank you all.
On Jun 22, 2007, at 7:52 PM, Roman Haefeli wrote:
On Fri, 2007-06-22 at 19:40 +0200, Roman Haefeli wrote:
On Fri, 2007-06-22 at 19:22 +0200, Roman Haefeli wrote:
one solution, that might would work, came to my
20 matches
Mail list logo
