[PD] dropout save metro

Roman Haefeli reduzierer at yahoo.de
Fri Jun 22 19:52:56 CEST 2007


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





More information about the Pd-list mailing list