Forums
I think we had this topic once but I want to bring it into attention a 2nd time.
I have a complex setup with Insert/Send to external hardware and software. Its roundtrip latency cannot be determined by jack reliably. With LSP Plugins Latency Meter it's very easy to determine it.
It would be super cool if there was an entry in View->Options->Audio similar to ...
Applied offset (latency correction) for audio clips after recording:
[X] Automatic [ _] Manual (frames) (insert here the same ms display and latency input box as in insert sends)
re. Manual audio clip recording latency compensation...
yes, back in the late year: Audio clip recording latency compensation ...
not forgotten :)
ps. one question remains: is this new optional input latency value to override the current computation, that applies to each audio bus in particular OR should be added to that value (in which case the "Automatic" option makes no sense)?
Replace
The manual override setting should replace the automatically (from jack, I think) determined value. If I set it to 1000 frames then the audio clip's offset after recording should be set to 1000 frames.
re. Replace...
overriden then,...
and this applies to ALL and every audio clip that gets recorded no matter where their tracks are fed (ie. an input audio bus), no matter the session, a global, absolute and permanent value that is...
is this correct? or better asked, is this what you really want?
Yes
It might make sense as a per session value, too, but I am afraid no-one would expect to find it in the session properties.
So I think it's safest as a global, permanent value.
beg to disagree...
in session properties would be the most suitable IMNSHO :)
also, now that we are at it, the following options should be provided:
cheers
ok
Yes, that's cool.
thinking again...
maybe the OP is a better approach, for the time being...
meaning that should not be installed as session properties but on global options instead, as designated originally.
though the above modal options should be provided, ntl.
sorry for the noise
Don't worry
I'll be happy with any solution.
it's live
qtractor >= v1.5.11.16git.8e0d67
nb. the 'None' mode option above is not implemented as it's functionally equivalent to 'Fixed' at 0 frames. ;)
test && tell
Not yet perfect
1.) Qtractor has to be restarted, else it doesn't activate the fixed value. This will make it look as non-working.
2.) The recorded audio clip's offset is not the fixed value but the sum of the automatic and the fixed value
Fixed should be fixed and not added, else you can't set the value determined by the latency test tool but have to do some math. And some MIDI-users recording external synths might want to set it to less then the automatic value.
maybe fixed...
on both accounts: qtractor >= 1.5.11.17git.4117ea
thanks
nearly perfect
No restart neccessary, thats good.
auto gives 18 ms on the clip
fixed 30 ms gives 32 ms on the clip (2 too much)
add 30 ms gives 47 (1 less)
Rounding errors? 2 at "fixed" seems to be too much for a rounding error.
It's incorrect on the frames level already
auto: 875 frames
fixed 1440: 1575 (should be 1440)
add 1440: 2300 (should be 2315)
rounding errors...
are not quite errors, rather the result of normalizing the clip offset to current MIDI resolution (frames to ticks and back) that depends on the actual clip location in the timeline--think tempo-map...
however, this automatic refitting has been there for ages and applies to both audio and MIDI clips, so it's all working as designed, I'd say :)
cheers
Acceptable
Doesn't make sense IMHO for audio clip offsets, but won't kill cute little kittens :)
Thanks for implementing it.
re. rounding errors...
no more in qtractor >= v1.5.11.18git.0daf11
subject to your kind assessment :)
cheers
99%
auto: 863 frames
fixed 1440: 1586 (not correct)
add 1440: 2303 (correct, 863+1440=2303)
re. 99%...
not the result I'd expect
making it Fixed 1234 frames here makes it exactly a 1234 frames offset on a recorded clip.
something is failing on us or one of us :/
screencast
That's how I do it.
1 bufsize off
It's depending on the jackd buffer size. When entering 1000 frames I get an offset of 1000 + bufsize, tested with bufsizes 64, 128, 256, 512 on 2 different machines (an oldish Ubuntu and a not so oldish Debian Bookworm).
Maybe it doesn't happen with pipewire.
re. 1 bufsize off...
indeed, on genuine jackd it adds exactly one buffersize up... but only if you set (jack)transport mode to Slave or Full...
otherwise it behaves exactly as under pipewire(-jack) premises
seeya
strange
Yes, that's very strange, but I can live with it.
Thanks again.
transport latency...
is not taken into account anymore, when capture latency mode is set on 'Fixed':
qtractor >= v1.5.11.19git.b8ab0c
sorry for the noise.
100%
This is great. Thanks a lot.
Add new comment