[PD] dropout save metro

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


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 at 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





More information about the Pd-list mailing list