Hey there, I'm currently trying to reproduce this in a minimal example to forward to @johannes. It turns out, it's not a problem with the xfade, but with the processing order of objects (which somehow seems to be determined by the x,y position in the patch!).
Check out this patch: processing_order_bug_test.axp (2.2 KB)
Positioning the oscillator between the two math/-c-objects makes everything work as expected:
Putting the oscillator above or below the
math/-c-objects seems to result in an invalid processing order, where one
math/-c is processed before the other and the
math/- gets the current buffer from one and the old buffer from the other, resulting in a glitch:
This is the most minimal example I can think of. Removing the math/-c-objects destroys the bug, but that is to be expected, as the math/--object gets the same buffer on both of its inputs then.
Looking at the version with the glitch, this is the execution order:
instancescope__2_i.dsp(net2Latch, net0Latch, (int8_t *)(&displayVector[3]));
instancesquare__1_i.dsp(0 , 0, net0, PExch[PARAM_INDEX_square__1_pitch].finalvalue);
instancescope__4_i.dsp(net1Latch, net0, (int8_t *)(&displayVector[35]));
instance_dash_c__1_i.dsp(net1Latch, net3, PExch[PARAM_INDEX__dash_c__1_c].finalvalue);
instance_dash___1_i.dsp(net3, net4Latch, net2);
instance_dash_c__2_i.dsp(net1Latch, net4, PExch[PARAM_INDEX__dash_c__2_c].finalvalue);
instancesaw__1_i.dsp(0 , net1, PExch[PARAM_INDEX_saw__1_pitch].finalvalue);
It seems weird to me why the scope_2 should be processed first?! It does the upper math/-c first, then the math/- and then the lower math/-c. Which is exactly what we see on the scope.
EDIT: Maybe a mod can split this into a separate topic on the helpdesk-subforum? @thetechnobear maybe?
