[PD] 0 length delay in delwrite~

[Matt Barber]

>
> BTW: having a [delread~] at a smaller block size than the [delwrite~] will
> create junk output because [delread~] will read at a faster rate than
> [delwrite~] can actually update the buffer, leading to weird looking
> repetitions in the waveform.


​I think this is more a function of the way [delread~] is written: it
doesn't maintain its own phase in the ​buffer but rather indexes from the
current [delwrite~] phase. If the latter has a larger blocksize,, then
[delread~] will repeat some blocks and then jump once the [delwrite~] is
updated. Getting [delread~] to maintain its own phase is very tricky (after
all the nature of delay means indexing from the writehead); it's not
impossible, but far from trivial.

On Sun, Dec 13, 2015 at 8:01 AM, Christof Ressi <christof.ressi at gmx.at>
wrote:

> > don't work for block size < 64
>
> true! mea culpa. just write [delwrite~ 1.5] + [delread~ 0] and
> everything's fine :-).
>
>
> > Those two things means the same to me, where maximum delay time = buffer
> size. I don't get this.
>
> The are *not* the same. I'll try to explain it:
> If you just want to send a signal (without delaying it), you still need a
> buffer for writing a signal block, which all the receive objects can then
> read from. Let's say the buffer size is 64 samples. If you, however, want
> to have a delay, you have to add a certain amount of samples according to
> the desired maximum delay time. If you want a max. delay of 1 second, you
> have to add 44100 samples. So the actual buffer size is 44164 samples. The
> delay time is really just a offset to your index in a ring buffer. Let's
> suppose one of the [delread~] objects is operating on a block size of 1024:
> the necessary size for reading without any delay is now 960 samples larger
> (1024-64), so in the buffer there are less samples left for actually
> delaying the signal: the maximum delay time for this particular [delread~]
> object is only 43410 samples.
>
> Of course Miller could add some complicated mechanism for [delwrite~] to
> keep track of all the block sizes of its [delread~] objects, but to me the
> simplest solution is updating the docs and stating: "max. delay time =
> buffer size - block size of [delread~]"
>
>
> > I might see an issue if delread~ is in a subpatch that has a longer
> block size, but I don't wee why anyone would need that, and perhaps just
> say you shouldn't do it.
>
> I *have* to do it when I read a delay line from inside a fft subpatch
> where the blocksize is of course larger than the one from the parent patch
> (didn't you have to do that as well? We talked about that in the thread
> concerning your phase vocoder issues a couple of months ago).
>
> BTW: having a [delread~] at a smaller block size than the [delwrite~] will
> create junk output because [delread~] will read at a faster rate than
> [delwrite~] can actually update the buffer, leading to weird looking
> repetitions in the waveform.
>
>
>
> Gesendet: Samstag, 12. Dezember 2015 um 18:00 Uhr
> Von: "Alexandre Torres Porres" <porres at gmail.com>
> An: "Roman Haefeli" <reduzent at gmail.com>, "i go bananas" <
> hard.off at gmail.com>, "Christof Ressi" <christof.ressi at gmx.at>, "Miller
> Puckette" <mpuckett at imusic1.ucsd.edu>
> Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> Betreff: Re: [PD] 0 length delay in delwrite~
>
> > Order forcing works well for me. Just set the [delwrite~] to 10 (
>
> but weirdness arises from 0 length delay.
>
> > If a delay of zero WAS actually permitted, these would form infinite
> loops.
>
> Don't think so, depends on what a 0 delay is. If it is "no delay", and by
> that I mean "No Buffer", then it only outputs 0 values, right?. In other
> words, nothing happens, no infinite loop, nothing, just zeros...
>
> but if instead of zeros it does have some buffer length in it, then a
> feedback delay will always de delayed at least one block size, so no
> worries about feedback loop.
>
> Actually, you need to set delread to "0" for a minimum block size delay.
> Perhaps you meant you couldn't or shouldn't put a "0" delay time in the
> delread~ object for feedback, but actually you NEED to do that.
>
> Thing is that I just use delwrite~ and delread~ with 0 length arguments
> for both and a block size of 1 to allow single sample feedback. I do it
> cause I wanted the minimum delay buffer size as possible and I didn't want
> to write in tiny and long and boring numbers according to one sample size
> depending on sample rate.
>
> Since it was working, I had just always assumed it would create a buffer
> of one block.
>
> This is not what's really happening as I see it.
>
> I don't really care that much on what happens, doesn't seem like a big
> deal, but it was nice to understand this behaviour. It doesn't seem very
> consistent, that's all I can say...
>
> Now, what it actually does is really just a matter of design choices. It
> could very much just create no delay buffer at all, where you'd get 0
> values perhaps, like I imagined. That's silly anyway...
>
> Or... it could be only one sample... or one block... I had assumed out of
> nowhere that it could be a block size, but it could much be just a single
> sample, which seems to make sense and it'd be cool I guess.
>
> What's really bad is that you need to always put a value that is at least
> one block size. It's a bug considering the documentation clearly stated
> that the design was really supposed to be a delay between 0 and max delay
> size, but one way or another, it's really annoying doing all this math as a
> workaround, when it's just a matter of coding it properly to allow any size
> greater than 0 and smaller than a block size (in orther words, to fix it).
>
> > If you, however, want a simple block delay in a feedback loop,
> > just use a pair of [send~] and [receive~].
>
> don't work for block size < 64
>
> > specifying the buffer size makes much more
> > sense then giving a maximum delay time
>
> Those two things means the same to me, where maximum delay time = buffer
> size. I don't get this.
>
> > [delwrite~] object would need to keep track of this
>
> sure, whatever, why not?
>
> by the way, that's the one that defines the max delay length (or buffer
> size), (and there can be only one, by the way) - so it only needs to keep
> track of its block size to work out the proper buffer size.
>
> I might see an issue if delread~ is in a subpatch that has a longer block
> size, but I don't wee why anyone would need that, and perhaps just say you
> shouldn't do it.
>
> I think we've discussed this before, perhaps just make sure both are in
> the same block size. I for one, never needed them to be in different block
> sizes, makes no useful sense.
>
> But anyway, I guess Miller is the one that should hop in and share his
> thoughts.
>
> and lets not forget the "clear" method, also important :)
>
> cheers
>
>
> 2015-12-12 12:33 GMT-02:00 Roman Haefeli <reduzent at gmail.com>:
> On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote:
> > hi, I'm checking that if you put a 0 length delay in delwrite~ you
> > still have some buffer
> >
> >
> > what's up with that? and how does it work? how big is it when you
> > don't define it?
>
> Don't know. I confirm that weirdness happens when setting [delwrite~] to
> 0. In other words: The only value that does not justify using a delay at
> all shows unexpected behavior. I can live with that.
>
> > I always get a minimum dealy even with order forcing (and different
> > values depending on extended orvanilla), it seems the delay needs to
> > be at least the block size to work properly
> >
> >
> > moreover, I can't have an order forcing
>
> Order forcing works well for me. Just set the [delwrite~] to 10 (and
> [delread~] to 0) in your patch and the number box shows 0 (this means
> zero delay, right?).
>
> Roman
>
>
> _______________________________________________
> Pd-list at lists.iem.at[Pd-list at lists.iem.at] mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151213/629a8182/attachment-0001.html>