[PD] more delay weirdness

[Alexandre Torres Porres]

2015-09-24 9:53 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:

> If my last post felt like a repression, I deeply regret that!
>

no worries ;) just had to bring it up.

but you were calling other things a bug, that were no bugs in a technical
> sense (how ms are calculated in overlapping subpatches, how the maximum
> index for [vd~] is actual less than the buffer size, etc.).
> (...)
> I'm personally rather careful with calling something a bug because chances
> are high that there's simply a technical reason I didn't consider or
> couldn't understand.
>

Yeah, I see the way you think but I think quite differently and I still
consider these things a "bug". I know there might be technical issues that
explain why things happen. But when nothing tells me that when using an
overlapped block that I have to adjust time and frequency for objects, I
see that as a bug, cause I'm expecting the object to behave as it should,
and it just doesn't, and then my patches don't work and it sucks. I have to
ask the list why the heck something is not happening and why do I need
workarounds... someone had to look deeply in the code and sort it out...

Well, and instead of building workarounds in the patch, I know there's a
way to "fix" this in the object (just divide by the overlap number
automatically in the code, seems easier than explaining it somewhere in the
help file of a block~) - it wouldn't be impossible to fix it.

Regarding the maximum delay time. Well, help file says it can go up to the
total length and it doesn't... so... bug detected. I'm sure there's a
reason why it's happening, but I don't think its impossible to fix it and
make it happen as well.

but anyway, I get your view, but I'll just disagree :) not sure if we
should discuss and try to change each other's minds.

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150924/d0cc6cfc/attachment.html>