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 <[email protected]>: > > 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" <[email protected]> > *An:* "Christof Ressi" <[email protected]> > *Cc:* Pd-List <[email protected]> > *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 <[email protected]>: >> >> 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 <[email protected]>: >>> >>> 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... >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
