what do you exactly mean by built-in io and external io?
examples would be helpful to ensure, I don’t go off at a tangent 
do you mean something like, a preset with
IN → OUT
STE → PLTS → OUT
k, so the short answer to this is yes and no…
(im going to talk theory here, as there are all kind of practical truths as well )
the most important part of ‘solving this’ is that the latency must be FIXED, if we have variable latency/jitter… its never truly solvable. fortunately, I believe this is generally true.
the next thing to understand is this is caused by buffer delays (each buffer is 128 samples @ 48k) , and depending on preset its going to be different.
e.g. if i have a patch like
IN (audio) → OUT
IN (trig) → PLTS → OUT
in theory this is in sync, since the trig will sync PLTS , i.e. audio and cv are the same.
then we have other factors like:
- certain modules may cause internal delays due to DSP, this can be a fractional buffer delay (e.g. 32 samples)
- where the delay is ‘fixed’, is dependent on the preset. e.g. if you send two audio signals to the same fx, you likely want the compensation before the fx.
- the synthor signal path creates buffer delays, due to order of processing of modules.
the point being latency is preset dependent, so it cannot be ‘fixed’ automatically.
(same is true of latency compensation in a DAW, for same reason)
solution? delay compensation.
basically you delay ‘tracks’ to the longest latency path in the preset.
note: there is no such thing as ‘negative delay compensation’ in a real time system, where daws depict this, they really are just adding positive delay to all other tracks… ie… its a ui trick
can already solve now?
yes, my SWAT module contains a micro delay algo, that allows for sample level delays.
is this perfect? nothing is
using SWAT is very flexible, but not the most user friendly… but hey, if you haven’t tried it you should… the idea of swat, is to find functions that are useful to users, and then consider ‘promoting’ them IF they prove useful. i.e. trial by fire… so i dont have to develop modules users think they need.
I could consider a simple micro delay module…that is more focused on this particular problem.
an alternative is adding a delay compensation feature to PMIX.
its not ideal, because as I said, where you fix latency is NOT always at the mixing stage… and to pretend it is, is an over simplification.
(e.g. in many cases it would be better to use SWAT w/ dly straight after INP)
however, it may be its a quick n’ simple solution for many presets.
… only drawback, is it requires yet more UI, and also will make PMIX use more memory, since it will require delay lines for all input channels, and they could be quite large, to be useful in all cases… but I can kind of optimize this, in a similar way to the way Ive done in the new DLYD module/].
but as i said, this will still require user knowledge, its not possible for the SSP to just ‘fix’ it.
