2015-12-11 14:59 GMT-02:00 Christof Ressi christof.ressi@gmx.at:

This is related to the discussion we had some month ago about the maximum delay length in [delread~] and [vd~]. Remember: the arguement for [delwrite~] is actually the buffer size and not the maximum delay length (-> bug in the docs).

Yeah, and I'll keep saying it is a bug in the object, and that the object should be fixed in order to be consistent with its description. I have to say I'm sometimes surprised on how things that don't work properly are usually treated as harmless features even though they were clearly designed to work in a different and more convenient way ;)

Apparantly, [delwrite] doesn't check for the minium buffer size and just acts weird if you set it to 0.

yeah, I'm pointing that out.

By the way, i should note that I've been using this (buffer size of "0") in subpatch with a block size of 1 to performe single sample feedback. I then had always thought that the minimum delay size was "one block" size - which, by the way, seems to me like a clever design.

I tried to test it further and check it through, well, it's just really crazy.

BTW: [delwrite~ 1.45125] + [delread~ 0] roughly equals a pair of [send~]

and [receive~]

bug detected, btw ;)

cheers

...

I'll keep saying it is a bug in the object, and that the object should be fixed in order to be consistent with its description.

Or one could change the description to be consistent with the behaviour ;-). Once again, specifying the buffer size makes much more sense then giving a maximum delay time, because the latter one is dependend on the blocksize. As the various [delread~] objects can operate at different blocksizes (which can also change during runtime) the [delwrite~] object would need to keep track of this. In some cases, a change of blocksize for a single [delread~] would even need a memory reallocation for the whole delay line. So specifying the buffer size is the easiest way. [delread~] could, however, add 64 samples to the buffer, so that for 'regular' subpatches, the buffer size equals the maximum delay line (this is actually the behaviour of [vd~], which is not consistent with [delwrite~] by the way). Personally I think we should hide as little as possible from the user and just make it clear in the help-patch, that buffer size != max. delay time.

Actually I don't understand your example: if [delwrite~] and [delread~] are scheduled, specifying a maximum delay time of 0 is pointless. If you, however, want a simple block delay in a feedback loop, just use a pair of [send~] and [receive~].

Cheers

Gesendet: Freitag, 11. Dezember 2015 um 18:33 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] 0 length delay in delwrite~

2015-12-11 14:59 GMT-02:00 Christof Ressi christof.ressi@gmx.at:This is related to the discussion we had some month ago about the maximum delay length in [delread~] and [vd~]. Remember: the arguement for [delwrite~] is actually the buffer size and not the maximum delay length (-> bug in the docs).   Yeah, and I'll keep saying it is a bug in the object, and that the object should be fixed in order to be consistent with its description. I have to say I'm sometimes surprised on how things that don't work properly are usually treated as harmless features even though they were clearly designed to work in a different and more convenient way ;)  Apparantly, [delwrite] doesn't check for the minium buffer size and just acts weird if you set it to 0.   yeah, I'm pointing that out.   By the way, i should note that I've been using this (buffer size of "0") in  subpatch with a block size of 1 to performe single sample feedback. I then had always thought that the minimum delay size was "one block" size - which, by the way, seems to me like a clever design.   I tried to test it further and check it through, well, it's just really crazy.    BTW: [delwrite~ 1.45125] + [delread~ 0] roughly equals a pair of [send~] and [receive~]   bug detected, btw ;)   cheers

The argument for [delwrite~] is the buffer size and *not* the maximum delay time. A buffer size of 0 doesn't make sense, you should set it to the highest block length you're using any of your [delread~] objects. Typing 1.5 will work if everything is at block size 64.

Gesendet: Samstag, 12. Dezember 2015 um 15:33 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] 0 length delay in delwrite~

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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

There's one trick that works for zero delay and [delwrite~ 0], based on the code of [delread~]: provide a negative delay time (with abs(delay time) > 1 sample).

Here's what's going on in Alexandre's patch.

[delwrite~ 0] sets up a buffer that is 68 samples long, plus four extra for interpolation in [vd~], which we needn't worry about here.

delwrite's float method is this:

/*---------------------------------------------------------------------------*/ static void sigdelread_float(t_sigdelread *x, t_float f) { int samps; t_sigdelwrite *delwriter = (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); x->x_deltime = f; if (delwriter) { int delsize = delwriter->x_cspace.c_n; x->x_delsamps = (int)(0.5 + x->x_sr * x->x_deltime) + x->x_n - x->x_zerodel; if (x->x_delsamps < x->x_n) x->x_delsamps = x->x_n; else if (x->x_delsamps > delwriter->x_cspace.c_n - DEFDELVS) x->x_delsamps = delwriter->x_cspace.c_n - DEFDELVS; } } /*---------------------------------------------------------------------------*/

Here, I believe that because the write and read are sorted, x->x_zerodel == 0. Also DEFDELVS == 64, and delwriter->x_cspace.c_n == 68; So with [delread~ 0], x->x_delsamps is initialized to 0 + 64 - 0. The first if statement fails, but the second one passes, and x_delsamps is set to c_n

• DEFDELVS = 4.

Let's pick it up after [delwrite~]'s second block calculation. It's just gotten the range 64:127 in its input vector, and written indices 64:67 with 64:67, and indices 0:59 with 68:127. Its phase is now at index 60. With x_delsamps set to 4, [delread~ 0] begins reading at index 60-4 = 56, which contains the value 124. For four samples, the difference between input and output (the [-~] in the patch) is -60. Indices 60:67 contain values 60:67, and 0:59 contain 68:127; the difference between input and output is therefore 8 for the 60 remaining samples of the block. Hence the oscillation between 8 and 60 in the number box, with 8 appearing most of the time.

If you set a negative delay, the first if statement passes, and x_delsamps is set to 64, as it should be to get zero delay (that is, it's reading the last 64 samples written to the delay buffer, so there's zero difference between input and output).

Matt

On Sat, Dec 12, 2015 at 12:00 PM, Alexandre Torres Porres porres@gmail.com wrote:

...

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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

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@gmail.com 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 Cc: "pd-list@lists.iem.at" pd-list@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@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@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]

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.

Yeah, this is exactly what I mean! Thanks for phrasing it in clearer way :-)

Gesendet: Sonntag, 13. Dezember 2015 um 16:23 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" hard.off@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] 0 length delay in delwrite~

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@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@gmail.com[porres@gmail.com]> An: "Roman Haefeli" <reduzent@gmail.com[reduzent@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, "Miller Puckette" <mpuckett@imusic1.ucsd.edu[mpuckett@imusic1.ucsd.edu]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmail.com[reduzent@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@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]

Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]

In our phase vocoder patches we could've set the [delwrite~] to the same blocksize as the fft subpatch. But what if we'd have several fft subpatches operating at different window sizes? Then you would need one [delwrite~] for each [delread~]. In my opinion, being able to use [delwrite~] and [delread~] at different blocksizes is a nice feature, so what about a nice little warning in the docs that you have to care about the buffer size if you're using different blocksizes? Maybe [delwrite~] could add extra 64 samples when allocating so that most users don't have to care about blocksize issues when using delay lines in a trivial way. Additionally there could be a subpatch in the help file with some advanced advice regarding block size issues.

At least we all agree that there's a mismatch between the docs and the actual behaviour.

After all, I've noticed that [delwrite~] performs memory allocation differently whether one of the reading objects is sorted and whether it's [delread~] or [vd~]. This is a little bit confusing.

Gesendet: Sonntag, 13. Dezember 2015 um 17:38 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" mpuckett@imusic1.ucsd.edu, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] 0 length delay in delwrite~

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?

What's the problem with sending a signal to delwrite~ with the same block size?   Moreover, are we saying you can't change this feature in the object because it'd break the feature of allowing different block sizes? Meaning that different block sizes are really important in specific cases?   My phase vocoder patch had a delwrite~ in the parent patch, but it doesn't make it any better, I still have a problem the last 1024 samples or so screw it up because of this delay legth bug. I remember I tried other things, block sizes and etc, nothing made it work. But what I'm saying is that I don't believe it *has* to be at a different block size and that things are buggy anyway. I still don't get all you've explained, but I'll take it and intuitively understand that different block sizes are a bitch. As I don't see why we'd need that, just have them at the same size, and fix this buffer length bug, it can be as long as you want, really, from 1 sample to whatever (specified as the argument).   cheers     2015-12-13 11:01 GMT-02:00 Christof Ressi christof.ressi@gmx.at:> 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@gmail.com[porres@gmail.com]> An: "Roman Haefeli" <reduzent@gmail.com[reduzent@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, "Miller Puckette" <mpuckett@imusic1.ucsd.edu[mpuckett@imusic1.ucsd.edu]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmail.com[reduzent@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@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]

and we can make it a "0" length delwrite~ to have a buffer that's one block long, that makes sense from our discussion, as I thought...

2015-12-13 15:34 GMT-02:00 Alexandre Torres Porres porres@gmail.com:

...

At least we all agree that there's a mismatch between the docs and the actual behaviour.

that's a start

In my opinion, being able to use [delwrite~] and [delread~] at different

...

blocksizes is a nice feature, so what about a nice little warning in the docs that you have to care about the buffer size if you're using different blocksizes?

Even failing to see how one thing prevents the other, my point is that you need to care about buffer size ALL OF THE TIME... it's never Good.

And in my point of view, it's just so simple: *add a bunch of samples to the delay* ; work that internally

Of course Miller could add some complicated mechanism for [delwrite~] to

...

keep track of all the block sizes of its [delread~] objects.

That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me.

...

, but to me the simplest solution is updating the docs and stating: "max. delay time = buffer size - block size of [delread~]"

Might be "simpler", but the craziest, and also the laziest, turning the user and patching experience into a nightmare. You're asking us to check all the block sizes and do the math ourselves and then convert it to ms and then insert it into a delwrite~ object... why live so hard?

cheers

Well, it's just a matter of opinion, you think it's unnecessary and I couldn't disagree more, we could just get it over with :)

But tell me, deep inside, if it did just work without you bothering with anything, would that be a problem to you? Cause it'd be a huge relief for me...

It's not even for me, I guess I could live with that, but I teach Pd for almost a decade now, I know something about newcomers... I'm an advocate of Pd and I try to make it as accessible and easy as possible, and I'd really have a problem with telling them (well, you gotta worry about all this stuff because there is a mentality in the Pd world that it'd be "unnecessary" for this to be automatically worked out for the user).

My life in Pd world is mostly devoted to teaching and advocating Pd as an user friendly tool, it has this power...

just think outside your mind a little, think about other people that are not you... why would you insist in saying things are unnecessary just because you don't mind doing it - do you mind *not* doing it? What would you lose? Why making a case out of it?

well, again, in the end, it's a matter of opinion, but as a tie-breaking criteria, I think that making it easier for more people and more user friendly should count.

cheers

2015-12-13 15:54 GMT-02:00 Christof Ressi christof.ressi@gmx.at:

...

add a bunch of samples to the delay ; work that internally

In a way, I agree on that, just add 64 samples so everything works for trivial use cases at block size 64. If you're using delay lines with other block sizes you're doing advanced stuff anyway.

...

why live so hard?

Given that everything is documented cleanly, there's no higher math involved in getting the right buffer size, just a multiplication and a subtraction ;-).

...

That doesn't seem crazy, get them all, check their block size, stay with

the greater block size, work it out interbally, voilà...

...

all the worries are over. Not too crazy and just elegant simple coding.

You're treating this as a mission impossible where it's quite trivial to me.

I never said it's a mission impossible. I just said it's unnecessary. If [delwrite~] has fixed buffer size, why should it constantly change only because I change the block size in some subpatch? To me this sounds rather absurd. It's not like that we don't have to care about a lot things on our own (just think of fft subpatches!).

Gesendet: Sonntag, 13. Dezember 2015 um 18:34 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" mpuckett@imusic1.ucsd.edu, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: [PD] 0 length delay in delwrite~

...

At least we all agree that there's a mismatch between the docs and the actual behaviour.

that's a start

In my opinion, being able to use [delwrite~] and [delread~] at different blocksizes is a nice feature, so what about a nice little warning in the docs that you have to care about the buffer size if you're using different blocksizes?

Even failing to see how one thing prevents the other, my point is that you need to care about buffer size ALL OF THE TIME... it's never Good.

And in my point of view, it's just so simple: add a bunch of samples to the delay ; work that internally

Of course Miller could add some complicated mechanism for [delwrite~] to keep track of all the block sizes of its [delread~] objects.

That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me. , but to me the simplest solution is updating the docs and stating: "max. delay time = buffer size - block size of [delread~]"

Might be "simpler", but the craziest, and also the laziest, turning the user and patching experience into a nightmare. You're asking us to check all the block sizes and do the math ourselves and then convert it to ms and then insert it into a delwrite~ object... why live so hard?

cheers

So I'm quite astonished that you're accusing me of throwing around with apodictic statements

you're right, I was too harsh

sorry

2015-12-13 16:37 GMT-02:00 Christof Ressi christof.ressi@gmx.at:

...

just think outside your mind a little, think about other people that are

not you...

I'm just giving my personal opinion. I can understand that you want to have more things working 'under the hood' and I'm in the opposite camp. But that's fine and as always the truth lies in the middle. If Miller decides that [delwrite~] should check for the block sizes of all the [delread] objects, that's perfectly fine for me. No matter how stuff is implemented, the most important thing is that it's fully documented. I agree that Pd should be as accessible as possible, but that's mostly a matter of documentation.

...

why would you insist in saying things are unnecessary just because you

don't mind doing it

I'm giving personal opinions and I'm clearly marking them as such (adding phrases like "I think", "in my opinion"). So I'm quite astonished that you're accusing me of throwing around with apodictic statements.

Gesendet: Sonntag, 13. Dezember 2015 um 19:09 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" mpuckett@imusic1.ucsd.edu, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: Re: [PD] 0 length delay in delwrite~

Well, it's just a matter of opinion, you think it's unnecessary and I couldn't disagree more, we could just get it over with :)

But tell me, deep inside, if it did just work without you bothering with anything, would that be a problem to you? Cause it'd be a huge relief for me...

It's not even for me, I guess I could live with that, but I teach Pd for almost a decade now, I know something about newcomers... I'm an advocate of Pd and I try to make it as accessible and easy as possible, and I'd really have a problem with telling them (well, you gotta worry about all this stuff because there is a mentality in the Pd world that it'd be "unnecessary" for this to be automatically worked out for the user).

My life in Pd world is mostly devoted to teaching and advocating Pd as an user friendly tool, it has this power...

just think outside your mind a little, think about other people that are not you... why would you insist in saying things are unnecessary just because you don't mind doing it - do you mind *not* doing it? What would you lose? Why making a case out of it?

well, again, in the end, it's a matter of opinion, but as a tie-breaking criteria, I think that making it easier for more people and more user friendly should count.

cheers

2015-12-13 15:54 GMT-02:00 Christof Ressi christof.ressi@gmx.at:> add a bunch of samples to the delay ; work that internally

In a way, I agree on that, just add 64 samples so everything works for trivial use cases at block size 64. If you're using delay lines with other block sizes you're doing advanced stuff anyway.

...

why live so hard?

Given that everything is documented cleanly, there's no higher math involved in getting the right buffer size, just a multiplication and a subtraction ;-).

...

That doesn't seem crazy, get them all, check their block size, stay with

the greater block size, work it out interbally, voilà...

...

all the worries are over. Not too crazy and just elegant simple coding.

You're treating this as a mission impossible where it's quite trivial to me.

I never said it's a mission impossible. I just said it's unnecessary. If [delwrite~] has fixed buffer size, why should it constantly change only because I change the block size in some subpatch? To me this sounds rather absurd. It's not like that we don't have to care about a lot things on our own (just think of fft subpatches!).

Gesendet: Sonntag, 13. Dezember 2015 um 18:34 Uhr Von: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Miller Puckette" <mpuckett@imusic1.ucsd.edu[mpuckett@imusic1.ucsd.edu]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@lists.iem.at]> Betreff: Re: Re: Re: [PD] 0 length delay in delwrite~

...

At least we all agree that there's a mismatch between the docs and the actual behaviour.

that's a start

In my opinion, being able to use [delwrite~] and [delread~] at different blocksizes is a nice feature, so what about a nice little warning in the docs that you have to care about the buffer size if you're using different blocksizes?

Even failing to see how one thing prevents the other, my point is that you need to care about buffer size ALL OF THE TIME... it's never Good.

And in my point of view, it's just so simple: add a bunch of samples to the delay ; work that internally

Of course Miller could add some complicated mechanism for [delwrite~] to keep track of all the block sizes of its [delread~] objects.

That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me. , but to me the simplest solution is updating the docs and stating: "max. delay time = buffer size - block size of [delread~]"

Might be "simpler", but the craziest, and also the laziest, turning the user and patching experience into a nightmare. You're asking us to check all the block sizes and do the math ourselves and then convert it to ms and then insert it into a delwrite~ object... why live so hard?

cheers

But tell me, deep inside, if it did just work without you bothering with anything, would that be a problem to you? Cause it'd be a huge relief for me...

And what do you want to say with this line? That I shouldn't contribute to your threads? No problem... I'm just trying to be helpful, though, by explaining some stuff and giving some personal opinions. I could, however, restrict myself to the former one and refrain from the latter one. :-)

Gesendet: Sonntag, 13. Dezember 2015 um 19:09 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" mpuckett@imusic1.ucsd.edu, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: Re: [PD] 0 length delay in delwrite~

Well, it's just a matter of opinion, you think it's unnecessary and I couldn't disagree more, we could just get it over with :)

But tell me, deep inside, if it did just work without you bothering with anything, would that be a problem to you? Cause it'd be a huge relief for me...   It's not even for me, I guess I could live with that, but I teach Pd for almost a decade now, I know something about newcomers... I'm an advocate of Pd and I try to make it as accessible and easy as possible, and I'd really have a problem with telling them (well, you gotta worry about all this stuff because there is a mentality in the Pd world that it'd be "unnecessary" for this to be automatically worked out for the user).

My life in Pd world is mostly devoted to teaching and advocating Pd as an user friendly tool, it has this power...

just think outside your mind a little, think about other people that are not you... why would you insist in saying things are unnecessary just because you don't mind doing it - do you mind *not* doing it? What would you lose? Why making a case out of it?   well, again, in the end, it's a matter of opinion, but as a tie-breaking criteria, I think that making it easier for more people and more user friendly should count.   cheers   2015-12-13 15:54 GMT-02:00 Christof Ressi christof.ressi@gmx.at:>  add a bunch of samples to the delay ; work that internally

In a way, I agree on that, just add 64 samples so everything works for trivial use cases at block size 64. If you're using delay lines with other block sizes you're doing advanced stuff anyway.

why live so hard?

Given that everything is documented cleanly, there's no higher math involved in getting the right buffer size, just a multiplication and a subtraction ;-).

That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me.

I never said it's a mission impossible. I just said it's unnecessary. If [delwrite~] has fixed buffer size, why should it constantly change only because I change the block size in some subpatch? To me this sounds rather absurd. It's not like that we don't have to care about a lot things on our own (just think of fft subpatches!).

Gesendet: Sonntag, 13. Dezember 2015 um 18:34 Uhr Von: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Miller Puckette" <mpuckett@imusic1.ucsd.edu[mpuckett@imusic1.ucsd.edu]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: Re: Re: [PD] 0 length delay in delwrite~

At least we all agree that there's a mismatch between the docs and the actual behaviour.

that's a start

In my opinion, being able to use [delwrite~] and [delread~] at different blocksizes is a nice feature, so what about a nice little warning in the docs that you have to care about the buffer size if you're using different blocksizes?   Even failing to see how one thing prevents the other, my point is that you need to care about buffer size ALL OF THE TIME... it's never Good.   And in my point of view, it's just so simple: add a bunch of samples to the delay ; work that internally   Of course Miller could add some complicated mechanism for [delwrite~] to keep track of all the block sizes of its [delread~] objects.   That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me.  , but to me the simplest solution is updating the docs and stating: "max. delay time = buffer size - block size of [delread~]"   Might be "simpler", but the craziest, and also the laziest, turning the user and patching experience into a nightmare. You're asking us to check all the block sizes and do the math ourselves and then convert it to ms and then insert it into a delwrite~ object... why live so hard?   cheers

To make things more complicated, [vd~] behaves differently, it keeps the extra 64 samples. see the attached patch.

Gesendet: Sonntag, 13. Dezember 2015 um 20:35 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Alexandre Torres Porres" porres@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] 0 length delay in delwrite~

The docs are right in one sense (at least for block = 64), but probably misleading: min delay possible is zero, but to get zero delay [delwrite~] needs to compute before [delread~]. Max delay is given in [delwrite~], but to attain the max delay, [delread~] needs to compute before [delwrite~]. There's a symmetry to it.   The piece of code I can't figure out is this. When the buffer is allocated, it actually does add 64 samples to the size:   /*--------------------------------------------------------------*/

int nsamps = x->x_deltime * sr * (t_float)(0.001f);     if (nsamps < 1) nsamps = 1;     nsamps += ((- nsamps) & (SAMPBLK - 1));     nsamps += DEFDELVS; /*DEFDLVS == 64/* /*--------------------------------------------------------------*/   But when you set the delay in [delread~], it clips the size of the buffer to (size - 64 == buffer size specified in [delwrite~]):   /*--------------------------------------------------------------*/

x->x_delsamps = (int)(0.5 + x->x_sr * x->x_deltime)             + x->x_n - x->x_zerodel;         if (x->x_delsamps < x->x_n) x->x_delsamps = x->x_n;         else if (x->x_delsamps > delwriter->x_cspace.c_n - DEFDELVS)             x->x_delsamps = delwriter->x_cspace.c_n - DEFDELVS; /*--------------------------------------------------------------*/     I don't have time to puzzle through this right now, but I'm not sure what DEFDELVS is actually designed to do.   On Sun, Dec 13, 2015 at 1:09 PM, Alexandre Torres Porres porres@gmail.com wrote: Well, it's just a matter of opinion, you think it's unnecessary and I couldn't disagree more, we could just get it over with :)

But tell me, deep inside, if it did just work without you bothering with anything, would that be a problem to you? Cause it'd be a huge relief for me...   It's not even for me, I guess I could live with that, but I teach Pd for almost a decade now, I know something about newcomers... I'm an advocate of Pd and I try to make it as accessible and easy as possible, and I'd really have a problem with telling them (well, you gotta worry about all this stuff because there is a mentality in the Pd world that it'd be "unnecessary" for this to be automatically worked out for the user).

My life in Pd world is mostly devoted to teaching and advocating Pd as an user friendly tool, it has this power...

just think outside your mind a little, think about other people that are not you... why would you insist in saying things are unnecessary just because you don't mind doing it - do you mind *not* doing it? What would you lose? Why making a case out of it?   well, again, in the end, it's a matter of opinion, but as a tie-breaking criteria, I think that making it easier for more people and more user friendly should count.   cheers

2015-12-13 15:54 GMT-02:00 Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]>:>  add a bunch of samples to the delay ; work that internally

In a way, I agree on that, just add 64 samples so everything works for trivial use cases at block size 64. If you're using delay lines with other block sizes you're doing advanced stuff anyway.

why live so hard?

Given that everything is documented cleanly, there's no higher math involved in getting the right buffer size, just a multiplication and a subtraction ;-).

That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me.

I never said it's a mission impossible. I just said it's unnecessary. If [delwrite~] has fixed buffer size, why should it constantly change only because I change the block size in some subpatch? To me this sounds rather absurd. It's not like that we don't have to care about a lot things on our own (just think of fft subpatches!).

Gesendet: Sonntag, 13. Dezember 2015 um 18:34 Uhr Von: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Miller Puckette" <mpuckett@imusic1.ucsd.edu[mpuckett@imusic1.ucsd.edu]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: Re: Re: [PD] 0 length delay in delwrite~

At least we all agree that there's a mismatch between the docs and the actual behaviour.

that's a start

In my opinion, being able to use [delwrite~] and [delread~] at different blocksizes is a nice feature, so what about a nice little warning in the docs that you have to care about the buffer size if you're using different blocksizes?   Even failing to see how one thing prevents the other, my point is that you need to care about buffer size ALL OF THE TIME... it's never Good.   And in my point of view, it's just so simple: add a bunch of samples to the delay ; work that internally   Of course Miller could add some complicated mechanism for [delwrite~] to keep track of all the block sizes of its [delread~] objects.   That doesn't seem crazy, get them all, check their block size, stay with the greater block size, work it out interbally, voilà... all the worries are over. Not too crazy and just elegant simple coding. You're treating this as a mission impossible where it's quite trivial to me.  , but to me the simplest solution is updating the docs and stating: "max. delay time = buffer size - block size of [delread~]"   Might be "simpler", but the craziest, and also the laziest, turning the user and patching experience into a nightmare. You're asking us to check all the block sizes and do the math ourselves and then convert it to ms and then insert it into a delwrite~ object... why live so hard?   cheers _______________________________________________ Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]