[PD] [vd~] VS [delread~] - different delay limit!

[Alexandre Torres Porres]

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 at 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150922/16790985/attachment-0001.html>