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