yeah, the patch I mentioned, is here 2015-09-23 11:34 GMT-03:00 Alexandre Torres Porres <[email protected]>:
> 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 >>>> >>> >>> >
Delay-limit-bug-delread.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
