[PD] Help

[Alexandre Torres Porres]

are you drowning or something?

2015-12-13 13:35 GMT-02:00 corentin THIERCELIN <corentoulf at hotmail.com>:

> Help
> Le 13 déc. 2015 16:25, pd-list-request at lists.iem.at a écrit :
> Send Pd-list mailing list submissions to
>         pd-list at lists.iem.at
>
> 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
>         pd-list-request at lists.iem.at
>
> You can reach the person managing the list at
>         pd-list-owner at lists.iem.at
>
> 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" <christof.ressi at gmx.at>
> To: "Alexandre Torres Porres" <porres at gmail.com>
> Cc: i go bananas <hard.off at gmail.com>, "pd-list at lists.iem.at"
>         <pd-list at lists.iem.at>
> Subject: Re: [PD] 0 length delay in delwrite~
> Message-ID:
>
> <trinity-26517955-f91f-441d-bebb-4d64585c8fec-1450011662710 at 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" <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
> ]
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 13 Dec 2015 10:23:31 -0500
> From: Matt Barber <brbrofsvl at gmail.com>
> To: Christof Ressi <christof.ressi at gmx.at>
> Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>, i go bananas
>         <hard.off at gmail.com>
> Subject: Re: [PD] 0 length delay in delwrite~
> Message-ID:
>         <
> CAOrke7H68ea46v_TiHPxBxzg8oduApvRqPjLCR5Kqcw2MP3N6w at 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 <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.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Pd-list mailing list
> Pd-list at lists.iem.at
> to manage your subscription (including un-subscription) see
> http://lists.puredata.info/listinfo/pd-list
>
>
> ------------------------------
>
> End of Pd-list Digest, Vol 129, Issue 58
> ****************************************
>
> _______________________________________________
> 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/2454dd37/attachment-0001.html>