are you drowning or something? 2015-12-13 13:35 GMT-02:00 corentin THIERCELIN <[email protected]>:
> Help > Le 13 déc. 2015 16:25, [email protected] a écrit : > Send Pd-list mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.puredata.info/listinfo/pd-list > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-list digest..." > > > Today's Topics: > > 1. Re: 0 length delay in delwrite~ (Christof Ressi) > 2. Re: 0 length delay in delwrite~ (Matt Barber) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 13 Dec 2015 14:01:02 +0100 > From: "Christof Ressi" <[email protected]> > To: "Alexandre Torres Porres" <[email protected]> > Cc: i go bananas <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [PD] 0 length delay in delwrite~ > Message-ID: > > <trinity-26517955-f91f-441d-bebb-4d64585c8fec-1450011662710@3capp-gmx-bs10 > > > > Content-Type: text/plain; charset=UTF-8 > > > 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 > ] > > > > > ------------------------------ > > Message: 2 > Date: Sun, 13 Dec 2015 10:23:31 -0500 > From: Matt Barber <[email protected]> > To: Christof Ressi <[email protected]> > Cc: "[email protected]" <[email protected]>, i go bananas > <[email protected]> > Subject: Re: [PD] 0 length delay in delwrite~ > Message-ID: > < > caorke7h68ea46v_tihpxbxzg8oduapvrqpjlcr5kqcw2mp3...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > > > > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.puredata.info/pipermail/pd-list/attachments/20151213/629a8182/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Pd-list mailing list > [email protected] > to manage your subscription (including un-subscription) see > http://lists.puredata.info/listinfo/pd-list > > > ------------------------------ > > End of Pd-list Digest, Vol 129, Issue 58 > **************************************** > > _______________________________________________ > [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
