Re: [PD] dropout save metro
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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, 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 have some dropouts. now you could send the output of
the 'dropout safe' [metro] to the audio instance of pd.
this would be a clean solution, but it requires some connection between
the two instances of pd, most probably a tcp-connection. due to this
connection, this approach might be inaccurate as well.
frank mentioned using an audio connection. with an audio connection
between both instances you wouldn't have any glitches. the main problem
is how to 'encode' and 'decode' the audio signal, so that you don't lose
sample accuracy. there are possibly many approaches, but one comes to
mind using [pack~] and [unpack~] from zexy. dependent on when the 'bang'
from the metro happens withing a block, you could encode that time into
the first sample of a block with a list like '23 0 0 0 0 0 . ' sent
to [pack~] . ('23' means, that the bang should be triggered at the 23th
sample of that block). on the receiver side, you could use an
[unpack~]
|
[$1]
construction to 'decode' the audio block.
hope, that makes sense..
(sorry for spaming so much about this topic)
i just realized, that you couldn't send higher values than '1' over an
audio connection. therefore the 'encode' should scaled down in order to
fit into the transmittable range.
roman
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
#N canvas 319 93 579 656 10;
#X declare -stdlib zexy;
#X obj 21 102 bang~;
#X obj 21 157 timer;
#X obj 102 123 metro 1000;
#X obj 21 181 - 0.7;
#X obj 21 203 unpack~;
#X obj 22 323 pack~;
#X obj 22 353 route 0;
#X obj 66 421 del;
#X obj 102 96 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X obj 66 567 timer;
#X obj 66 545 t b b;
#X floatatom 66 588 0 0 0 0 - - -;
#X floatatom 167 96 0 0 0 0 - - -;
#X msg 66 375 \$1;
#X obj 66 398 + 0.7;
#X obj 20 48 declare -stdlib zexy;
#X text 36 275 _;
#X text 237 246 pd instance 1;
#X text 242 317 pd instance 2;
#X text 155 393 instance two does all the audio stuff.;
#X text 155 410 though it sometimes has drop outs \, the metro-input
is not affected.;
#X text 25 269 - digital audio connnection (e.g. jack);
#X text 135 176 instance 1 should run with higher priority and runs
only this part (- no drop outs are expected here);
#X text 128 566 - measures period;
#X text 24 5 this patch tries to show how an implementation of a 'drop
out safe' [metro] with two instances of pd could look like.;
#X connect 0 0 1 0;
#X connect 1 0 3 0;
#X connect 2 0 1 1;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 1 13 0;
#X connect 7 0 10 0;
#X connect 8 0 2 0;
#X connect 9 0 11 0;
#X connect 10 0 9 0;
#X connect 10 1 9 1;
#X connect 12 0 2 1;
#X connect 13 0 14 0;
#X connect 14 0 7 0;
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
[PD] dropout save metro
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 difference between [timer] and [realtime], I don't understand what is the meaning of 'same with both' in your sentence. i meant: both are realtime based Did you get my email about [timer] not reporting realtime at all? Or have you said [timer] again when you meant [time] ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 both. 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. i meant: both are realtime based Did you get my email about [timer] not reporting realtime at all? Or have you said [timer] again when you meant [time] ? oh, man, i am too muddle-headed. i did the exact same typo again. i still meant to talk about [time]. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 wormholes are fiction ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] dropout save metro
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] dropout save metro
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 periods between the 'ticks' and calculated the new delay time. i just discovered [time] from zexy which is the system time ... has anyone yet built a metro with [time] ? :) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 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 periods between the 'ticks' and calculated the new delay time. i just discovered [time] from zexy which is the system time ... has anyone yet built a metro with [time] ? :) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 underlying architecture of pd correctly. first, you cannot be sure, that each desired time will be triggered. lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. in that case '43 297' 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, that it doesn't matter at all, when the [metro] object is processed by pd, the output of it will be accurate (as long there are no dropouts). with a purely realtime based solution, you'll never know, when exactly the object, that does the time measuring, is processed. the time, when [timer] receives your bang is not exactly defined and can happen anywhere between now and the amount of your buffersize later. correct me, if i am wrong, but as i understand pd, there will be no accurate realtime based solution. roman On Fri, 2007-06-22 at 17:56 +0200, Enrique Erne wrote: 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 periods between the 'ticks' and calculated the new delay time. i just discovered [time] from zexy which is the system time ... has anyone yet built a metro with [time] ? :) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 sync with outside. the realmetro could have 2 outlets one for events in time the other for the ones who are too late. if i had a realmetro i'd built a realcounter that'd output 1 _ 3 4 5 6 but still no idea how it can get achieved :( On Jun 22, 2007, at 6:11 PM, chris clepper wrote: 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 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 periods between the 'ticks' and calculated the new delay time. i just discovered [time] from zexy which is the system time ... has anyone yet built a metro with [time] ? :) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 done in plain pd? Some quick ideas: Use an external metro and receive it with netreceive/OSC. This will be quantized to message blocks of course, but maybe OSC timestamps can be used. jack_transport: Will only work on systems with jack. I don't know, if there's an external available, but it shouldn't be too hard to write. [adc~]: Use a click signal coming in over [adc~]. Advantage: This will not be quantized. But you need some objects to make use of these signal clicks. Eric Lyon wrote some, they are in CVS. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 'dropout safe' [metro] to the audio instance of pd. this would be a clean solution, but it requires some connection between the two instances of pd, most probably a tcp-connection. due to this connection, this approach might be inaccurate as well. roman On Fri, 2007-06-22 at 19:06 +0200, Enrique Erne wrote: 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 approach would *might* work, but it has several disadvantages, if i do understand the underlying architecture of pd correctly. first, you cannot be sure, that each desired time will be triggered. lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. in that case '43 297' 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, that it doesn't matter at all, when the [metro] object is processed by pd, the output of it will be accurate (as long there are no dropouts). with a purely realtime based solution, you'll never know, when exactly the object, that does the time measuring, is processed. the time, when [timer] receives your bang is not exactly defined and can happen anywhere between now and the amount of your buffersize later. correct me, if i am wrong, but as i understand pd, there will be no accurate realtime based solution. roman On Fri, 2007-06-22 at 17:56 +0200, Enrique Erne wrote: 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 periods between the 'ticks' and calculated the new delay time. i just discovered [time] from zexy which is the system time ... has anyone yet built a metro with [time] ? :) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 have some dropouts. now you could send the output of
the 'dropout safe' [metro] to the audio instance of pd.
this would be a clean solution, but it requires some connection between
the two instances of pd, most probably a tcp-connection. due to this
connection, this approach might be inaccurate as well.
frank mentioned using an audio connection. with an audio connection
between both instances you wouldn't have any glitches. the main problem
is how to 'encode' and 'decode' the audio signal, so that you don't lose
sample accuracy. there are possibly many approaches, but one comes to
mind using [pack~] and [unpack~] from zexy. dependent on when the 'bang'
from the metro happens withing a block, you could encode that time into
the first sample of a block with a list like '23 0 0 0 0 0 . ' sent
to [pack~] . ('23' means, that the bang should be triggered at the 23th
sample of that block). on the receiver side, you could use an
[unpack~]
|
[$1]
construction to 'decode' the audio block.
hope, that makes sense..
roman
On Fri, 2007-06-22 at 19:06 +0200, Enrique Erne wrote:
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 approach would *might* work, but it has several disadvantages, if
i
do understand the underlying architecture of pd correctly. first, you
cannot be sure, that each desired time will be triggered. lets assume
you want to schedule the next 'bang' to 43s297ms, but the output of
[timer] maybe is '43 296', '43 296', '43 298'. in that case '43 297'
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,
that it doesn't matter at all, when the [metro] object is processed by
pd, the output of it will be accurate (as long there are no dropouts).
with a purely realtime based solution, you'll never know, when exactly
the object, that does the time measuring, is processed. the time, when
[timer] receives your bang is not exactly defined and can happen
anywhere between now and the amount of your buffersize later.
correct me, if i am wrong, but as i understand pd, there will be no
accurate realtime based solution.
roman
On Fri, 2007-06-22 at 17:56 +0200, Enrique Erne wrote:
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 periods between the 'ticks' and
calculated the new delay time.
i just discovered [time] from zexy which is the system time
... has anyone yet built a metro with [time] ? :)
eni
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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. the second pd does all the audio stuff
and therefore might have some dropouts. now you could send the output of
the 'dropout safe' [metro] to the audio instance of pd.
this would be a clean solution, but it requires some connection between
the two instances of pd, most probably a tcp-connection. due to this
connection, this approach might be inaccurate as well.
frank mentioned using an audio connection. with an audio connection
between both instances you wouldn't have any glitches. the main problem
is how to 'encode' and 'decode' the audio signal, so that you don't lose
sample accuracy. there are possibly many approaches, but one comes to
mind using [pack~] and [unpack~] from zexy. dependent on when the 'bang'
from the metro happens withing a block, you could encode that time into
the first sample of a block with a list like '23 0 0 0 0 0 . ' sent
to [pack~] . ('23' means, that the bang should be triggered at the 23th
sample of that block). on the receiver side, you could use an
[unpack~]
|
[$1]
construction to 'decode' the audio block.
hope, that makes sense..
(sorry for spaming so much about this topic)
i just realized, that you couldn't send higher values than '1' over an
audio connection. therefore the 'encode' should scaled down in order to
fit into the transmittable range.
roman
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 approach would *might* work, but it has several disadvantages, if i do understand the underlying architecture of pd correctly. first, you cannot be sure, that each desired time will be triggered. lets assume you want to schedule the next 'bang' to 43s297ms, but the output of [timer] maybe is '43 296', '43 296', '43 298'. in that case '43 297' 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, that it doesn't matter at all, when the [metro] object is processed by pd, the output of it will be accurate (as long there are no dropouts). with a purely realtime based solution, you'll never know, when exactly the object, that does the time measuring, is processed. the time, when [timer] receives your bang is not exactly defined and can happen anywhere between now and the amount of your buffersize later. correct me, if i am wrong, but as i understand pd, there will be no accurate realtime based solution. roman On Fri, 2007-06-22 at 17:56 +0200, Enrique Erne wrote: 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 periods between the 'ticks' and calculated the new delay time. i just discovered [time] from zexy which is the system time ... has anyone yet built a metro with [time] ? :) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout save metro
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 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 'dropout safe' [metro] to the audio instance of pd.
this would be a clean solution, but it requires some connection
between
the two instances of pd, most probably a tcp-connection. due to this
connection, this approach might be inaccurate as well.
frank mentioned using an audio connection. with an audio connection
between both instances you wouldn't have any glitches. the main
problem
is how to 'encode' and 'decode' the audio signal, so that you don't
lose
sample accuracy. there are possibly many approaches, but one comes to
mind using [pack~] and [unpack~] from zexy. dependent on when the
'bang'
from the metro happens withing a block, you could encode that time
into
the first sample of a block with a list like '23 0 0 0 0 0 . '
sent
to [pack~] . ('23' means, that the bang should be triggered at the
23th
sample of that block). on the receiver side, you could use an
[unpack~]
|
[$1]
construction to 'decode' the audio block.
hope, that makes sense..
(sorry for spaming so much about this topic)
i just realized, that you couldn't send higher values than '1' over an
audio connection. therefore the 'encode' should scaled down in order to
fit into the transmittable range.
roman
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
