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