Comments by lorenzolamasse
Wondering btw if the remaining latency is not linked to vector size, not sure as there is some jitter on it anyway. I guess that's one of the limitations of M4L to be a hassle when it comes to latency compensation.
Posted on January 14 2021 by lorenzolamasse |
Report Issue |
See Comment
Agree with latest post, there is a slight latency I have not been able to get rid of. The thing is that when transport is sampled, there still are some actions to be done before outputting the note, and we have no control on these actions whatsoever.
Replaced transport par plugsync~ that is supposed to be very accurate and revamped the architecture to have it occur exactly on time, but I still have around 0.5ms of latency no matter what. Does not happen when using Live's builtin arpeggiator sending out midi to another channel. I've ended up quantizing record to 1/32nd on target track which is accurate enough for my needs.
Maybe there is somewhere a m4l function to bang at a specific time the midi out message ?
Replaced transport par plugsync~ that is supposed to be very accurate and revamped the architecture to have it occur exactly on time, but I still have around 0.5ms of latency no matter what. Does not happen when using Live's builtin arpeggiator sending out midi to another channel. I've ended up quantizing record to 1/32nd on target track which is accurate enough for my needs.
Maybe there is somewhere a m4l function to bang at a specific time the midi out message ?