I haven’t tried this out on my H9000 yet, but a few things I can see for potential issues.
The pico delay is executed before the crossin so the crossin input from the picodelay is always going to be delayed by 1 sample (or however many samples the processor lag is) even if picodelay is set to 0. I was thinking about ways to solve this for my own feedback filter algorithms (which can get runaway feedback, but I’m seeing that as a feature at the moment for some stuff I’m doing), and I think that there will need to be some delay in the dry signal after the feedback loop but before the outputs to align the dry signal with the outputs, if we want true sample accuracy in feedback loops.
The other thought I had was perhaps to set up some input and output shift registers using the pico delay and using those to feedback or inject, similar to how shift registers in labView work, but I haven’t worked through this yet to see if it’s possible or how to implement it.
My thinking is that each of the dsp blocks is going to introduce some latency and the only way to really line things up at the sample level is going to be to introduce delays on the dry input and to pull the suitably delayed signal when it is required. To reliably do this though will need us to understand the latency of each block, which isn’t available either in the help file, or in the .json database. I think the only way to find out would either be for Eventide to supply it (if they know) or for us to measure each block, which is somewhere in my todo list for the future. Eventide may also have put some form of latency compensation in, so that may be another potential spanner in the works.
Another potential issue (and I don’t think this will directly affect your signal chain) is that I’ve found audio signals don’t seem to do what I expect with regards to absolute numbers.
The 0-1 in crossin modulation is most likely silence to full scale audio, which don’t necessarily correspond to the digits 0 and 1 (even though the help file says that’s what it’s expecting). You may be better off using a volume control or something similar to feed your mod input from an oscillator. I’ve fallen into this trap a few times trying to do a similar thing to what you are attempting here. As I’ve said I haven’t tested your algorithm yet, and if it works, don’t mess with it, but if the crossfade isn’t doing what you are expecting, this could be a reason. Also, the math.bound may be a better option than the c_bound, if you need it, and put it on the audio line.
