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

[Alexandre Torres Porres]

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/6d9fa662/attachment.html>