> > 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 <[email protected]> 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" <[email protected]> > An: "Roman Haefeli" <[email protected]>, "i go bananas" < > [email protected]>, "Christof Ressi" <[email protected]>, "Miller > Puckette" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 <[email protected]>: > 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 > > > _______________________________________________ > [email protected][[email protected]] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list] > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
