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
