the actual limit of the delay line is the buffersize minus the windows
size
actually, I made some tests and it is the (buffersize - windows size + one block 0f 64 samples).
But anyway, this limitation is what I perceived, but I fail to see why any such limitation should happen. If the delay is "x" long, we should be able to read from "x" behind in time... if not, there's a bug in it. That's how I see it, and why I marked this issue as a potential bug.
From the [vd~] help file, it says
"The delay time is always at least one sample *and at most the length of the delay line (specified by the delwrite~)*"
So if we can't read it at most from the specified delay line, there's a bug!
since the delay line is only written for every block and you want to read the last N samples from the delay line, [vd~] simply clips to the maximum reading index.
Again, I fail to see a reason here. If such a limitation happens, maybe the object could be coded in a way that it allows an extra something to make it possible a total length read out.
But I thought that maybe the order forcing of delay objects could be something to take into consideration. Well, I did the order forcing and many such tests, but nothing really changed!
I have then the latest version attached. I'm copying miller here and also sending to the list. I'll also post this as a bug report.
cheers
2015-09-21 16:45 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hey, as I suspected, you are simply hitting the limit of the delay line. You can test this on your own with the patch I've sent you. Note that the actual limit of the delay line is the buffersize minus the windows size, since the delay line is only written for every block and you want to read the last N samples from the delay line. [vd~] simply clips to the maximum reading index. Note that there isn't any phase difference anymore between the two windows after both have exceeded the limit.
Cheers
*Gesendet:* Montag, 21. September 2015 um 19:53 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" < pd-list@lists.iem.at> *Betreff:* Re: Re: PVoc patch "bug"? I've simplified the patch a lot so many things can be discarded.
The window size shouldn't affect anything as the reading point in the delay line is fixed. Now I don't have [vline~] or anything, just a steady signal fed to [vd~], when we get close to the end of the delay line it just gets ruined, and that's all that there is to it. There's no flaw in the patch, nothing I didn't think of. It's really something very mysterious or perhaps a bug.
The patch is now simpler and also vanilla compatible. I tried it in the new Pd Vanilla 0.46-7 and I got the same weird behaviour.
Check attachment please
cheers
2015-09-21 14:12 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Well, I just think you're hitting the limit of the delay line. Your window size is 2048 samples, so inside the subpatch that's 2048/(44,1*4) = 11,6 ms. But one window is one hop size (2,9 ms) behind, therefore 11,6 ms
- 2,9 ms = 14,5 ms and 1000 ms - 14,5 ms = 985,5 ms --> that's pretty much
the limit you were experiencing. Hope that helps.
Cheers *Gesendet:* Montag, 21. September 2015 um 18:27 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" < pd-list@lists.iem.at> *Betreff:* Re: PVoc patch "bug"? my patch has a little issue, I'm saying the delay line is 60000 ms (this is for the wrapping objects) when it's only 4000, but that is not a problem for what I'm asking here as the wrapping doesn't influence anything. It's just something weird that happens even without the wrapping.
I wonder what's the principle you'd have for not using cyclone :)
2015-09-21 12:32 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hey,
the first thing I noticed: your [delwrite~] is at 4000 ms, but [s $0-buff_size] is still fed with 60000 ms... Is this on purpose? The second thing: Even if you got the range for [pong~] right, my guess is that this will create a sudden jump from the end of the delay line to the beginning. You'd need some kind of enveloping to mask the discontinuity. Maybe this won't be noticeable if you pass the 'problematic' area quickly, but might sound terrible if you stay there. In your case, however, it seems that the delay line is simply clipped since you've sent a wrong value to [pong~]. This is just some remote diagnostics, though, since I don't use any cyclone objects as a matter of principle :-D.
Cheers
PS: I didn't put this on the list on purpose, because it's only about a specific patch and not something more general.
*Gesendet:* Montag, 21. September 2015 um 06:48 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "pd-list@lists.iem.at" pd-list@lists.iem.at, "Christof Ressi" < christof.ressi@gmx.at> *Betreff:* PVoc patch "bug"? Hi there, still struggling with my circular buffer Phase Vocoder, now I've found an issue that has no apparent reason.
Check the attached patch please
the speed is 100% and pitcnh shift is "0", so the signal from vline~ stands still in one particular point in the buffer (read from [vd~]).
buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" for it does oversampling with the overlap of 4 (we've discussed this before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way that works for the patch.
The point is, when getting close to the end of the delay line, things get ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as pointed above. You can check my patch and see how that goes.
If the reading point is at somewhere just after the buffer size less a window size plus a hop size (around 985 ms) things get bad.
I can't find a reason for that in a million years. Please help
thanks
2015-09-22 5:56 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
You're totally right that the sentence >The delay time is always at least one sample *and at most the length of the delay line (specified by the delwrite~)*< is misleading.
well, I still consider it to be a bug, it's not that it is misleading, it is just not happening because of bug. There's nothing to prevent you from reading a delay line to the maximum of what it was specified, if it can't, then the object is buggy. If it has some limitation of a block less or so, then there's a simple way to fix it, just add an extra block to the delay line and make it work. Anyway, I filed this as a bug report yesterday, I hope it gets checked upon soon, hopefully it'll work for the next Pd release (0.47).
BTW: There's a funny issue when the blocksize of the [delread~] is smaller than the blocksize of the [delwrite~]: In that case the [delread~] is reading more often than the delay line itself is actually updated, so you get repetitions of blocks.
Again, i think you can always code it to work around these issues. But in this case, I don't see why not have them both in the same block.
actually, I made some tests and it is the (buffersize - windows size +
one block 0f 64 samples). Are you sure?
yep, check the patch I sent, works on vanilla.
cheers
*Gesendet:* Montag, 21. September 2015 um 23:05 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "Miller Puckette" < mpuckett@imusic1.ucsd.edu>, "pd-list@lists.iem.at" pd-list@lists.iem.at *Betreff:* Delay time limit bug (was: PVoc patch "bug"?)
the actual limit of the delay line is the buffersize minus the windows
size
actually, I made some tests and it is the (buffersize - windows size + one block 0f 64 samples).
But anyway, this limitation is what I perceived, but I fail to see why any such limitation should happen. If the delay is "x" long, we should be able to read from "x" behind in time... if not, there's a bug in it. That's how I see it, and why I marked this issue as a potential bug.
From the [vd~] help file, it says
"The delay time is always at least one sample *and at most the length of the delay line (specified by the delwrite~)*"
So if we can't read it at most from the specified delay line, there's a bug!
since the delay line is only written for every block and you want to read the last N samples from the delay line, [vd~] simply clips to the maximum reading index.
Again, I fail to see a reason here. If such a limitation happens, maybe the object could be coded in a way that it allows an extra something to make it possible a total length read out.
But I thought that maybe the order forcing of delay objects could be something to take into consideration. Well, I did the order forcing and many such tests, but nothing really changed!
I have then the latest version attached. I'm copying miller here and also sending to the list. I'll also post this as a bug report.
cheers
2015-09-21 16:45 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hey, as I suspected, you are simply hitting the limit of the delay line. You can test this on your own with the patch I've sent you. Note that the actual limit of the delay line is the buffersize minus the windows size, since the delay line is only written for every block and you want to read the last N samples from the delay line. [vd~] simply clips to the maximum reading index. Note that there isn't any phase difference anymore between the two windows after both have exceeded the limit.
Cheers
*Gesendet:* Montag, 21. September 2015 um 19:53 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" < pd-list@lists.iem.at> *Betreff:* Re: Re: PVoc patch "bug"? I've simplified the patch a lot so many things can be discarded.
The window size shouldn't affect anything as the reading point in the delay line is fixed. Now I don't have [vline~] or anything, just a steady signal fed to [vd~], when we get close to the end of the delay line it just gets ruined, and that's all that there is to it. There's no flaw in the patch, nothing I didn't think of. It's really something very mysterious or perhaps a bug.
The patch is now simpler and also vanilla compatible. I tried it in the new Pd Vanilla 0.46-7 and I got the same weird behaviour.
Check attachment please
cheers
2015-09-21 14:12 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Well, I just think you're hitting the limit of the delay line. Your window size is 2048 samples, so inside the subpatch that's 2048/(44,1*4) = 11,6 ms. But one window is one hop size (2,9 ms) behind, therefore 11,6 ms
- 2,9 ms = 14,5 ms and 1000 ms - 14,5 ms = 985,5 ms --> that's pretty much
the limit you were experiencing. Hope that helps.
Cheers *Gesendet:* Montag, 21. September 2015 um 18:27 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" < pd-list@lists.iem.at> *Betreff:* Re: PVoc patch "bug"? my patch has a little issue, I'm saying the delay line is 60000 ms (this is for the wrapping objects) when it's only 4000, but that is not a problem for what I'm asking here as the wrapping doesn't influence anything. It's just something weird that happens even without the wrapping.
I wonder what's the principle you'd have for not using cyclone :)
2015-09-21 12:32 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hey,
the first thing I noticed: your [delwrite~] is at 4000 ms, but [s $0-buff_size] is still fed with 60000 ms... Is this on purpose? The second thing: Even if you got the range for [pong~] right, my guess is that this will create a sudden jump from the end of the delay line to the beginning. You'd need some kind of enveloping to mask the discontinuity. Maybe this won't be noticeable if you pass the 'problematic' area quickly, but might sound terrible if you stay there. In your case, however, it seems that the delay line is simply clipped since you've sent a wrong value to [pong~]. This is just some remote diagnostics, though, since I don't use any cyclone objects as a matter of principle :-D.
Cheers
PS: I didn't put this on the list on purpose, because it's only about a specific patch and not something more general.
*Gesendet:* Montag, 21. September 2015 um 06:48 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "pd-list@lists.iem.at" pd-list@lists.iem.at, "Christof Ressi" < christof.ressi@gmx.at> *Betreff:* PVoc patch "bug"? Hi there, still struggling with my circular buffer Phase Vocoder, now I've found an issue that has no apparent reason.
Check the attached patch please
the speed is 100% and pitcnh shift is "0", so the signal from vline~ stands still in one particular point in the buffer (read from [vd~]).
buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" for it does oversampling with the overlap of 4 (we've discussed this before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way that works for the patch.
The point is, when getting close to the end of the delay line, things get ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as pointed above. You can check my patch and see how that goes.
If the reading point is at somewhere just after the buffer size less a window size plus a hop size (around 985 ms) things get bad.
I can't find a reason for that in a million years. Please help
thanks
here's another example, there's a delay line with a size of 2048 samples, in patch with a block size of 2048, and the delay line is only able to delay a maximum of 64 samples
2015-09-22 14:07 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2015-09-22 5:56 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
You're totally right that the sentence >The delay time is always at least one sample *and at most the length of the delay line (specified by the delwrite~)*< is misleading.
well, I still consider it to be a bug, it's not that it is misleading, it is just not happening because of bug. There's nothing to prevent you from reading a delay line to the maximum of what it was specified, if it can't, then the object is buggy. If it has some limitation of a block less or so, then there's a simple way to fix it, just add an extra block to the delay line and make it work. Anyway, I filed this as a bug report yesterday, I hope it gets checked upon soon, hopefully it'll work for the next Pd release (0.47).
BTW: There's a funny issue when the blocksize of the [delread~] is smaller than the blocksize of the [delwrite~]: In that case the [delread~] is reading more often than the delay line itself is actually updated, so you get repetitions of blocks.
Again, i think you can always code it to work around these issues. But in this case, I don't see why not have them both in the same block.
actually, I made some tests and it is the (buffersize - windows size +
one block 0f 64 samples). Are you sure?
yep, check the patch I sent, works on vanilla.
cheers
*Gesendet:* Montag, 21. September 2015 um 23:05 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "Miller Puckette" < mpuckett@imusic1.ucsd.edu>, "pd-list@lists.iem.at" pd-list@lists.iem.at *Betreff:* Delay time limit bug (was: PVoc patch "bug"?)
the actual limit of the delay line is the buffersize minus the windows
size
actually, I made some tests and it is the (buffersize - windows size + one block 0f 64 samples).
But anyway, this limitation is what I perceived, but I fail to see why any such limitation should happen. If the delay is "x" long, we should be able to read from "x" behind in time... if not, there's a bug in it. That's how I see it, and why I marked this issue as a potential bug.
From the [vd~] help file, it says
"The delay time is always at least one sample *and at most the length of the delay line (specified by the delwrite~)*"
So if we can't read it at most from the specified delay line, there's a bug!
since the delay line is only written for every block and you want to
read
the last N samples from the delay line, [vd~] simply clips to the maximum reading index.
Again, I fail to see a reason here. If such a limitation happens, maybe the object could be coded in a way that it allows an extra something to make it possible a total length read out.
But I thought that maybe the order forcing of delay objects could be something to take into consideration. Well, I did the order forcing and many such tests, but nothing really changed!
I have then the latest version attached. I'm copying miller here and also sending to the list. I'll also post this as a bug report.
cheers
2015-09-21 16:45 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hey, as I suspected, you are simply hitting the limit of the delay line. You can test this on your own with the patch I've sent you. Note that the actual limit of the delay line is the buffersize minus the windows size, since the delay line is only written for every block and you want to read the last N samples from the delay line. [vd~] simply clips to the maximum reading index. Note that there isn't any phase difference anymore between the two windows after both have exceeded the limit.
Cheers
*Gesendet:* Montag, 21. September 2015 um 19:53 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" < pd-list@lists.iem.at> *Betreff:* Re: Re: PVoc patch "bug"? I've simplified the patch a lot so many things can be discarded.
The window size shouldn't affect anything as the reading point in the delay line is fixed. Now I don't have [vline~] or anything, just a steady signal fed to [vd~], when we get close to the end of the delay line it just gets ruined, and that's all that there is to it. There's no flaw in the patch, nothing I didn't think of. It's really something very mysterious or perhaps a bug.
The patch is now simpler and also vanilla compatible. I tried it in the new Pd Vanilla 0.46-7 and I got the same weird behaviour.
Check attachment please
cheers
2015-09-21 14:12 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Well, I just think you're hitting the limit of the delay line. Your window size is 2048 samples, so inside the subpatch that's 2048/(44,1*4) = 11,6 ms. But one window is one hop size (2,9 ms) behind, therefore 11,6 ms
- 2,9 ms = 14,5 ms and 1000 ms - 14,5 ms = 985,5 ms --> that's pretty much
the limit you were experiencing. Hope that helps.
Cheers *Gesendet:* Montag, 21. September 2015 um 18:27 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at *Betreff:* Re: PVoc patch "bug"? my patch has a little issue, I'm saying the delay line is 60000 ms (this is for the wrapping objects) when it's only 4000, but that is not a problem for what I'm asking here as the wrapping doesn't influence anything. It's just something weird that happens even without the wrapping.
I wonder what's the principle you'd have for not using cyclone :)
2015-09-21 12:32 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hey,
the first thing I noticed: your [delwrite~] is at 4000 ms, but [s $0-buff_size] is still fed with 60000 ms... Is this on purpose? The second thing: Even if you got the range for [pong~] right, my guess is that this will create a sudden jump from the end of the delay line to the beginning. You'd need some kind of enveloping to mask the discontinuity. Maybe this won't be noticeable if you pass the 'problematic' area quickly, but might sound terrible if you stay there. In your case, however, it seems that the delay line is simply clipped since you've sent a wrong value to [pong~]. This is just some remote diagnostics, though, since I don't use any cyclone objects as a matter of principle :-D.
Cheers
PS: I didn't put this on the list on purpose, because it's only about a specific patch and not something more general.
*Gesendet:* Montag, 21. September 2015 um 06:48 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "pd-list@lists.iem.at" pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at *Betreff:* PVoc patch "bug"? Hi there, still struggling with my circular buffer Phase Vocoder, now I've found an issue that has no apparent reason.
Check the attached patch please
the speed is 100% and pitcnh shift is "0", so the signal from vline~ stands still in one particular point in the buffer (read from [vd~]).
buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" for it does oversampling with the overlap of 4 (we've discussed this before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way that works for the patch.
The point is, when getting close to the end of the delay line, things get ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as pointed above. You can check my patch and see how that goes.
If the reading point is at somewhere just after the buffer size less a window size plus a hop size (around 985 ms) things get bad.
I can't find a reason for that in a million years. Please help
thanks
funny, I found out about the same thing and just posted on the thread that I'm reporting it as a bug
Well, my oppinion is that there might be some explanation why it happens, but also that both objects have bugs regarding the way they operate as they can't reach the delay limit when it comes to changing the block size, and they also have different limits... so both should be fixed to just be able to reach the specified maximum limit.
cheers
2015-09-22 15:17 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
In the course of a discussion with Alexandre I ran into something really interesting: [delread~] and [vd~] have different delay limits! While [delread~] has always the buffersize minus the blocksize of the subpatch where it is located, the limit of [vd~] is 64 samples greater. Any explanations?
In my example patch, simply choose any blocksize, then set the delay time to maximum 100 (which is actually beyond the maximum), and then toggle between [vd~] and [delread~] to see the 64 samples difference...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I found another difference between vd~ and delread~
vd~ will have that issue where you need to divide the time in ms for the overlap number - which I think is bad and maybe it should just work around that. It's really annoying working with a different time range.
now, delread~ doesn't need that, you can work with the actual ms
one way or another, it seems bad that both behave differently. I point they should work the same way and that vd~ behaves like delread~ in this case.
cheers
2015-09-22 15:34 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
funny, I found out about the same thing and just posted on the thread that I'm reporting it as a bug
Well, my oppinion is that there might be some explanation why it happens, but also that both objects have bugs regarding the way they operate as they can't reach the delay limit when it comes to changing the block size, and they also have different limits... so both should be fixed to just be able to reach the specified maximum limit.
cheers
2015-09-22 15:17 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
In the course of a discussion with Alexandre I ran into something really interesting: [delread~] and [vd~] have different delay limits! While [delread~] has always the buffersize minus the blocksize of the subpatch where it is located, the limit of [vd~] is 64 samples greater. Any explanations?
In my example patch, simply choose any blocksize, then set the delay time to maximum 100 (which is actually beyond the maximum), and then toggle between [vd~] and [delread~] to see the 64 samples difference...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
well, in my test in the attached patch, the delrwrite is at 4000 size, and delread will read all the way up there instead of only to about 1000 as vd~ does
I'd like to see your test please, as I dont know what to say, looks to me it is different. I didn't create a second thread cause I thought that another difference between them could be pointed here.
about your original question, I can't tell you why it behaves they behave differently, but I do strongly believe that whatever the reason is, this is a problem that should be fixed as they both should, in my view, be able to go up to the specified time limit.
cheers
2015-09-23 7:27 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
vd~ will have that issue where you need to divide the time in ms for the
overlap number -
which I think is bad and maybe it should just work around that. It's
really annoying working with a different time range.
now, delread~ doesn't need that, you can work with the actual ms
That's not true! They both convert the ms information to samples according to the actual samplerate of the subpatch where the object is located at. This is what I've been experiencing and I've checked it again.
So can we please come back to my initial question about the different delay limits of [vd~] and [delwrite~]?
*Gesendet:* Dienstag, 22. September 2015 um 21:32 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* Pd-List pd-list@lists.iem.at *Betreff:* Re: [PD] [vd~] VS [delread~] - different delay limit! I found another difference between vd~ and delread~
vd~ will have that issue where you need to divide the time in ms for the overlap number - which I think is bad and maybe it should just work around that. It's really annoying working with a different time range.
now, delread~ doesn't need that, you can work with the actual ms
one way or another, it seems bad that both behave differently. I point they should work the same way and that vd~ behaves like delread~ in this case.
cheers
2015-09-22 15:34 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
funny, I found out about the same thing and just posted on the thread that I'm reporting it as a bug
Well, my oppinion is that there might be some explanation why it happens, but also that both objects have bugs regarding the way they operate as they can't reach the delay limit when it comes to changing the block size, and they also have different limits... so both should be fixed to just be able to reach the specified maximum limit.
cheers
2015-09-22 15:17 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
In the course of a discussion with Alexandre I ran into something really interesting: [delread~] and [vd~] have different delay limits! While [delread~] has always the buffersize minus the blocksize of the subpatch where it is located, the limit of [vd~] is 64 samples greater. Any explanations?
In my example patch, simply choose any blocksize, then set the delay time to maximum 100 (which is actually beyond the maximum), and then toggle between [vd~] and [delread~] to see the 64 samples difference...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yeah, the patch I mentioned, is here
2015-09-23 11:34 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
well, in my test in the attached patch, the delrwrite is at 4000 size, and delread will read all the way up there instead of only to about 1000 as vd~ does
I'd like to see your test please, as I dont know what to say, looks to me it is different. I didn't create a second thread cause I thought that another difference between them could be pointed here.
about your original question, I can't tell you why it behaves they behave differently, but I do strongly believe that whatever the reason is, this is a problem that should be fixed as they both should, in my view, be able to go up to the specified time limit.
cheers
2015-09-23 7:27 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
vd~ will have that issue where you need to divide the time in ms for
the overlap number -
which I think is bad and maybe it should just work around that. It's
really annoying working with a different time range.
now, delread~ doesn't need that, you can work with the actual ms
That's not true! They both convert the ms information to samples according to the actual samplerate of the subpatch where the object is located at. This is what I've been experiencing and I've checked it again.
So can we please come back to my initial question about the different delay limits of [vd~] and [delwrite~]?
*Gesendet:* Dienstag, 22. September 2015 um 21:32 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* Pd-List pd-list@lists.iem.at *Betreff:* Re: [PD] [vd~] VS [delread~] - different delay limit! I found another difference between vd~ and delread~
vd~ will have that issue where you need to divide the time in ms for the overlap number - which I think is bad and maybe it should just work around that. It's really annoying working with a different time range.
now, delread~ doesn't need that, you can work with the actual ms
one way or another, it seems bad that both behave differently. I point they should work the same way and that vd~ behaves like delread~ in this case.
cheers
2015-09-22 15:34 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
funny, I found out about the same thing and just posted on the thread that I'm reporting it as a bug
Well, my oppinion is that there might be some explanation why it happens, but also that both objects have bugs regarding the way they operate as they can't reach the delay limit when it comes to changing the block size, and they also have different limits... so both should be fixed to just be able to reach the specified maximum limit.
cheers
2015-09-22 15:17 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
In the course of a discussion with Alexandre I ran into something really interesting: [delread~] and [vd~] have different delay limits! While [delread~] has always the buffersize minus the blocksize of the subpatch where it is located, the limit of [vd~] is 64 samples greater. Any explanations?
In my example patch, simply choose any blocksize, then set the delay time to maximum 100 (which is actually beyond the maximum), and then toggle between [vd~] and [delread~] to see the 64 samples difference...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi