[sdiy] 1 bit serial stream delay approaches..

[Jean-Pierre Desrochers]

Tom,
I was the one at the very beginning who actually asked for some
*easy* approaches to implement a shift register type delay
for an incoming *possibly complex* gate signal.
All that programmed  in C code on a small PIC micro.
Reading all the incoming posts I think I'll follow
the 'A' approach like yourself are suggesting.
More predictable and much easier.
Looks like a software BBD behaviour.
Thanks to all  !
J-Pierre



 On Mon 24/09/12 11:27 , Tom Wiltshire tom at electricdruid.net sent:
> So do it the first way - (A).
> 
> Designing a system such that it unnecessarily includes nightmare problems
> that you then have to (literally) sort out sounds like a definition of
> lunacy to me.
> I understand the potential for an event to finish up going out earlier than
> another in (B), but I don't see *why* anyone would want such a system, even
> if they could be bothered to implement it. The original post was looking
> for a simple way to implement a very long (5 second) shift register with
> good time resolution. (B) doesn't do that. (A) is much closer in both
> concept and output to a long shift register clocked with a variable
> clock.
> Tom
> 
> 
> On 24 Sep 2012, at 14:01, Olivier Gillet wrote:
> 
> >> Sounds to me like you're over-thinking this,
> unless I'm missing something. I don't see any problem with voltage-control
> of delay time, either way you implement it.> 
> > It depends on your delay semantics. If at time
> t, the delay time is> 500ms, does it mean:
> > A/ I should play at time t any event which was
> registered at t-500ms> B/ I should play at time t+500ms any incoming
> event.> 
> > If you follow the A/ approach, it's very easy to
> keep the event list> sorted - events are just added in order to it,
> and this can indeed be> done with a FIFO. A change in delay time will
> just rush the flushing> of the list...
> > 
> > But if you follow the B/ approach, here is what
> can happen (assuming> an initially empty event list):
> > - At time t, the delay time is 300ms and an
> event arrive, it is thus> scheduled for t+300ms - the event is inserted at
> the beginning of the> list
> > - At time t+10, the delay time is 200ms and an
> event arrive, it is> thus scheduled for t+210ms - the event must be
> inserted at the> beginning of the event list.
> > - At time t+20, the delay time is 400ms and an
> event arrive, it is> thus scheduled for t+420ms - the event must be
> inserted at the end of> the event list.
> > - At time t+30, the delay time is 100ms and an
> event arrive, it is> thus scheduled for t+130ms - the event must be
> inserted at the> beginning of the event list
> > 
> > Since the variation of delays might alter the
> order of events, you> might have to insert the event somewhere in the
> middle of the list,> which requires O(log n) operations if the event
> list is kept sorted> (and not O(n) as stated).
> > 
> > Olivier
> 
> _______________________________________________
> Synth-diy mailing list
> S
> ynth-diy at dropmix.xs4all.nlhttp://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 
>