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
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 pd@mild.ch 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
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 pd@mild.ch 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
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
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
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
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
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
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
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
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__
-
chris clepper -
Enrique Erne -
Frank Barknecht -
Roman Haefeli