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
-objects seems to result in an invalid processing order, where one
is processed before the other and the
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));
instancesquare__1_i.dsp(0 , 0, net0, PExch[PARAM_INDEX_square__1_pitch].finalvalue);
instancescope__4_i.dsp(net1Latch, net0, (int8_t *)(&displayVector));
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?