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

[Alexandre Torres Porres]

yeah, the patch I mentioned, is here

2015-09-23 11:34 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 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 at 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 at gmail.com>
>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>> *Cc:* Pd-List <pd-list at 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 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/20150923/a4d97806/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delay-limit-bug-delread.pd
Type: application/octet-stream
Size: 20807 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150923/a4d97806/attachment-0001.obj>