inconsistency in the delay module

[brok landers]

hi chris,

i found a "mistake" in the delay section. i know, it's "by design", but nevertheless it has a flaw. you are not "panning" the signal with the panner, but "balancing" it. hence, as soon as one pans the input signal pror the delay module to the opposite side of the panning in the delay itself, there's no delay. if you accurately "pan" it (meaning you sum up one channel onto the other by dragging the pan slider, rather than substracting one channel, as it is now), no matter where you pan the input signal to, there will always be delay, as then both inputs are used always, just as it should be.

[sonigen]

hi chris,

i found a "mistake" in the delay section. i know, it's "by design", but nevertheless it has a flaw. you are not "panning" the signal with the panner, but "balancing" it. hence, as soon as one pans the input signal pror the delay module to the opposite side of the panning in the delay itself, there's no delay. if you accurately "pan" it (meaning you sum up one channel onto the other by dragging the pan slider, rather than substracting one channel, as it is now), no matter where you pan the input signal to, there will always be delay, as then both inputs are used always, just as it should be.

To be honest I dont remember whether i did it that way on purpose or not, but you're right that it makes more sense to sum the channels onto each other.

Will fix it in the next update. (After tonights bugfix).

Thanks,