<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p dir="ltr">Help</p>
<div class="gmail_quote">Le 13 déc. 2015 16:25, pd-list-request@lists.iem.at a écrit :<br type="attribution">
</div>
<div class="BodyFragment">
<div class="PlainText">Send Pd-list mailing list submissions to<br>
pd-list@lists.iem.at<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
or, via email, send a message with subject or body 'help' to<br>
pd-list-request@lists.iem.at<br>
<br>
You can reach the person managing the list at<br>
pd-list-owner@lists.iem.at<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Pd-list digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: 0 length delay in delwrite~ (Christof Ressi)<br>
2. Re: 0 length delay in delwrite~ (Matt Barber)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 13 Dec 2015 14:01:02 +0100<br>
From: "Christof Ressi" <christof.ressi@gmx.at><br>
To: "Alexandre Torres Porres" <porres@gmail.com><br>
Cc: i go bananas <hard.off@gmail.com>, "pd-list@lists.iem.at"<br>
<pd-list@lists.iem.at><br>
Subject: Re: [PD] 0 length delay in delwrite~<br>
Message-ID:<br>
<trinity-26517955-f91f-441d-bebb-4d64585c8fec-1450011662710@3capp-gmx-bs10><br>
<br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
> don't work for block size < 64<br>
<br>
true! mea culpa. just write [delwrite~ 1.5] + [delread~ 0] and everything's fine :-).
<br>
<br>
<br>
> Those two things means the same to me, where maximum delay time = buffer size. I don't get this.<br>
<br>
The are *not* the same. I'll try to explain it: <br>
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. <br>
<br>
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~]"<br>
<br>
<br>
> 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.
<br>
<br>
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).<br>
<br>
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.<br>
<br>
<br>
<br>
Gesendet: Samstag, 12. Dezember 2015 um 18:00 Uhr<br>
Von: "Alexandre Torres Porres" <porres@gmail.com><br>
An: "Roman Haefeli" <reduzent@gmail.com>, "i go bananas" <hard.off@gmail.com>, "Christof Ressi" <christof.ressi@gmx.at>, "Miller Puckette" <mpuckett@imusic1.ucsd.edu><br>
Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at><br>
Betreff: Re: [PD] 0 length delay in delwrite~<br>
<br>
> Order forcing works well for me. Just set the [delwrite~] to 10 (<br>
<br>
but weirdness arises from 0 length delay.<br>
<br>
> If a delay of zero WAS actually permitted, these would form infinite loops. <br>
<br>
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...<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
Since it was working, I had just always assumed it would create a buffer of one block.<br>
<br>
This is not what's really happening as I see it.<br>
<br>
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...<br>
<br>
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...<br>
<br>
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.<br>
<br>
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).<br>
<br>
> If you, however, want a simple block delay in a feedback loop,<br>
> just use a pair of [send~] and [receive~].<br>
<br>
don't work for block size < 64<br>
<br>
> specifying the buffer size makes much more<br>
> sense then giving a maximum delay time<br>
<br>
Those two things means the same to me, where maximum delay time = buffer size. I don't get this.<br>
<br>
> [delwrite~] object would need to keep track of this<br>
<br>
sure, whatever, why not?<br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
But anyway, I guess Miller is the one that should hop in and share his thoughts.<br>
<br>
and lets not forget the "clear" method, also important :)<br>
<br>
cheers<br>
<br>
<br>
2015-12-12 12:33 GMT-02:00 Roman Haefeli <reduzent@gmail.com>:<br>
On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote:<br>
> hi, I'm checking that if you put a 0 length delay in delwrite~ you<br>
> still have some buffer<br>
><br>
><br>
> what's up with that? and how does it work? how big is it when you<br>
> don't define it?<br>
<br>
Don't know. I confirm that weirdness happens when setting [delwrite~] to<br>
0. In other words: The only value that does not justify using a delay at<br>
all shows unexpected behavior. I can live with that.<br>
<br>
> I always get a minimum dealy even with order forcing (and different<br>
> values depending on extended orvanilla), it seems the delay needs to<br>
> be at least the block size to work properly<br>
><br>
><br>
> moreover, I can't have an order forcing<br>
<br>
Order forcing works well for me. Just set the [delwrite~] to 10 (and<br>
[delread~] to 0) in your patch and the number box shows 0 (this means<br>
zero delay, right?).<br>
<br>
Roman<br>
<br>
<br>
_______________________________________________<br>
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list">
http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list</a>]<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 13 Dec 2015 10:23:31 -0500<br>
From: Matt Barber <brbrofsvl@gmail.com><br>
To: Christof Ressi <christof.ressi@gmx.at><br>
Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at>, i go bananas<br>
<hard.off@gmail.com><br>
Subject: Re: [PD] 0 length delay in delwrite~<br>
Message-ID:<br>
<CAOrke7H68ea46v_TiHPxBxzg8oduApvRqPjLCR5Kqcw2MP3N6w@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
><br>
> BTW: having a [delread~] at a smaller block size than the [delwrite~] will<br>
> create junk output because [delread~] will read at a faster rate than<br>
> [delwrite~] can actually update the buffer, leading to weird looking<br>
> repetitions in the waveform.<br>
<br>
<br>
I think this is more a function of the way [delread~] is written: it<br>
doesn't maintain its own phase in the buffer but rather indexes from the<br>
current [delwrite~] phase. If the latter has a larger blocksize,, then<br>
[delread~] will repeat some blocks and then jump once the [delwrite~] is<br>
updated. Getting [delread~] to maintain its own phase is very tricky (after<br>
all the nature of delay means indexing from the writehead); it's not<br>
impossible, but far from trivial.<br>
<br>
On Sun, Dec 13, 2015 at 8:01 AM, Christof Ressi <christof.ressi@gmx.at><br>
wrote:<br>
<br>
> > don't work for block size < 64<br>
><br>
> true! mea culpa. just write [delwrite~ 1.5] + [delread~ 0] and<br>
> everything's fine :-).<br>
><br>
><br>
> > Those two things means the same to me, where maximum delay time = buffer<br>
> size. I don't get this.<br>
><br>
> The are *not* the same. I'll try to explain it:<br>
> If you just want to send a signal (without delaying it), you still need a<br>
> buffer for writing a signal block, which all the receive objects can then<br>
> read from. Let's say the buffer size is 64 samples. If you, however, want<br>
> to have a delay, you have to add a certain amount of samples according to<br>
> the desired maximum delay time. If you want a max. delay of 1 second, you<br>
> have to add 44100 samples. So the actual buffer size is 44164 samples. The<br>
> delay time is really just a offset to your index in a ring buffer. Let's<br>
> suppose one of the [delread~] objects is operating on a block size of 1024:<br>
> the necessary size for reading without any delay is now 960 samples larger<br>
> (1024-64), so in the buffer there are less samples left for actually<br>
> delaying the signal: the maximum delay time for this particular [delread~]<br>
> object is only 43410 samples.<br>
><br>
> Of course Miller could add some complicated mechanism for [delwrite~] to<br>
> keep track of all the block sizes of its [delread~] objects, but to me the<br>
> simplest solution is updating the docs and stating: "max. delay time =<br>
> buffer size - block size of [delread~]"<br>
><br>
><br>
> > I might see an issue if delread~ is in a subpatch that has a longer<br>
> block size, but I don't wee why anyone would need that, and perhaps just<br>
> say you shouldn't do it.<br>
><br>
> I *have* to do it when I read a delay line from inside a fft subpatch<br>
> where the blocksize is of course larger than the one from the parent patch<br>
> (didn't you have to do that as well? We talked about that in the thread<br>
> concerning your phase vocoder issues a couple of months ago).<br>
><br>
> BTW: having a [delread~] at a smaller block size than the [delwrite~] will<br>
> create junk output because [delread~] will read at a faster rate than<br>
> [delwrite~] can actually update the buffer, leading to weird looking<br>
> repetitions in the waveform.<br>
><br>
><br>
><br>
> Gesendet: Samstag, 12. Dezember 2015 um 18:00 Uhr<br>
> Von: "Alexandre Torres Porres" <porres@gmail.com><br>
> An: "Roman Haefeli" <reduzent@gmail.com>, "i go bananas" <<br>
> hard.off@gmail.com>, "Christof Ressi" <christof.ressi@gmx.at>, "Miller<br>
> Puckette" <mpuckett@imusic1.ucsd.edu><br>
> Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at><br>
> Betreff: Re: [PD] 0 length delay in delwrite~<br>
><br>
> > Order forcing works well for me. Just set the [delwrite~] to 10 (<br>
><br>
> but weirdness arises from 0 length delay.<br>
><br>
> > If a delay of zero WAS actually permitted, these would form infinite<br>
> loops.<br>
><br>
> Don't think so, depends on what a 0 delay is. If it is "no delay", and by<br>
> that I mean "No Buffer", then it only outputs 0 values, right?. In other<br>
> words, nothing happens, no infinite loop, nothing, just zeros...<br>
><br>
> but if instead of zeros it does have some buffer length in it, then a<br>
> feedback delay will always de delayed at least one block size, so no<br>
> worries about feedback loop.<br>
><br>
> Actually, you need to set delread to "0" for a minimum block size delay.<br>
> Perhaps you meant you couldn't or shouldn't put a "0" delay time in the<br>
> delread~ object for feedback, but actually you NEED to do that.<br>
><br>
> Thing is that I just use delwrite~ and delread~ with 0 length arguments<br>
> for both and a block size of 1 to allow single sample feedback. I do it<br>
> cause I wanted the minimum delay buffer size as possible and I didn't want<br>
> to write in tiny and long and boring numbers according to one sample size<br>
> depending on sample rate.<br>
><br>
> Since it was working, I had just always assumed it would create a buffer<br>
> of one block.<br>
><br>
> This is not what's really happening as I see it.<br>
><br>
> I don't really care that much on what happens, doesn't seem like a big<br>
> deal, but it was nice to understand this behaviour. It doesn't seem very<br>
> consistent, that's all I can say...<br>
><br>
> Now, what it actually does is really just a matter of design choices. It<br>
> could very much just create no delay buffer at all, where you'd get 0<br>
> values perhaps, like I imagined. That's silly anyway...<br>
><br>
> Or... it could be only one sample... or one block... I had assumed out of<br>
> nowhere that it could be a block size, but it could much be just a single<br>
> sample, which seems to make sense and it'd be cool I guess.<br>
><br>
> What's really bad is that you need to always put a value that is at least<br>
> one block size. It's a bug considering the documentation clearly stated<br>
> that the design was really supposed to be a delay between 0 and max delay<br>
> size, but one way or another, it's really annoying doing all this math as a<br>
> workaround, when it's just a matter of coding it properly to allow any size<br>
> greater than 0 and smaller than a block size (in orther words, to fix it).<br>
><br>
> > If you, however, want a simple block delay in a feedback loop,<br>
> > just use a pair of [send~] and [receive~].<br>
><br>
> don't work for block size < 64<br>
><br>
> > specifying the buffer size makes much more<br>
> > sense then giving a maximum delay time<br>
><br>
> Those two things means the same to me, where maximum delay time = buffer<br>
> size. I don't get this.<br>
><br>
> > [delwrite~] object would need to keep track of this<br>
><br>
> sure, whatever, why not?<br>
><br>
> by the way, that's the one that defines the max delay length (or buffer<br>
> size), (and there can be only one, by the way) - so it only needs to keep<br>
> track of its block size to work out the proper buffer size.<br>
><br>
> I might see an issue if delread~ is in a subpatch that has a longer block<br>
> size, but I don't wee why anyone would need that, and perhaps just say you<br>
> shouldn't do it.<br>
><br>
> I think we've discussed this before, perhaps just make sure both are in<br>
> the same block size. I for one, never needed them to be in different block<br>
> sizes, makes no useful sense.<br>
><br>
> But anyway, I guess Miller is the one that should hop in and share his<br>
> thoughts.<br>
><br>
> and lets not forget the "clear" method, also important :)<br>
><br>
> cheers<br>
><br>
><br>
> 2015-12-12 12:33 GMT-02:00 Roman Haefeli <reduzent@gmail.com>:<br>
> On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote:<br>
> > hi, I'm checking that if you put a 0 length delay in delwrite~ you<br>
> > still have some buffer<br>
> ><br>
> ><br>
> > what's up with that? and how does it work? how big is it when you<br>
> > don't define it?<br>
><br>
> Don't know. I confirm that weirdness happens when setting [delwrite~] to<br>
> 0. In other words: The only value that does not justify using a delay at<br>
> all shows unexpected behavior. I can live with that.<br>
><br>
> > I always get a minimum dealy even with order forcing (and different<br>
> > values depending on extended orvanilla), it seems the delay needs to<br>
> > be at least the block size to work properly<br>
> ><br>
> ><br>
> > moreover, I can't have an order forcing<br>
><br>
> Order forcing works well for me. Just set the [delwrite~] to 10 (and<br>
> [delread~] to 0) in your patch and the number box shows 0 (this means<br>
> zero delay, right?).<br>
><br>
> Roman<br>
><br>
><br>
> _______________________________________________<br>
> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list<br>
> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list">
http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list</a>]<br>
><br>
><br>
> _______________________________________________<br>
> Pd-list@lists.iem.at mailing list<br>
> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.puredata.info/pipermail/pd-list/attachments/20151213/629a8182/attachment.html">http://lists.puredata.info/pipermail/pd-list/attachments/20151213/629a8182/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Pd-list mailing list<br>
Pd-list@lists.iem.at<br>
to manage your subscription (including un-subscription) see<br>
<a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Pd-list Digest, Vol 129, Issue 58<br>
****************************************<br>
</div>
</div>
</body>
</html>