On 01/29/2018 02:47 PM, Robert Jonsson wrote:
Hi Tim,
I saw your extensive fix for building static.
Just checked in a rather severe bug that I added in the last release
causing rather instant crashes when built for release, so I'm going for
making a release pretty soon.
There's one more I'd like to try and fix, renaming an Input track on
certain songs causes a lockup with certain songs for me. Not as fatal as
the other so if I don't find it soon I'll make the release first.
OK I'll keep an eye out for that one.
Meanwhile, about that "quick" latency fix I was mentioning:
Well, I've got a fix here for the audio recording side.
It works with one or more Audio Input tracks connected *directly*
to a Wave Track. As long as all the connected inputs have
the /same/ latency. It simply shifts the recorded wave's time.
Ehm... but there's a *problem* I'm not sure I considered
in the quick fix case: OK, we have recording compensation but
what about /playback/ latency?
I tested and realized that for example the metronome sounds
too late causing /me/ to play too late and when the recording is
played back it's out of sync - /even/ with these local fixes for the
input side. (The reason is that the recording would then have to
be shifted one /more/ period to compensate for the late playback,
but that's an incorrect fix.)
Notice that in the case of synths, like metronome, it is not
/audio/ latency that we must (or even can) compensate for,
it is the /midi/ input to the synth that will need to be
shifted ahead in time.
Pre-recorded waves also need to be shifted.
I am struggling. The solutions to this playback correction
problem seem puzzling.
When Jack transport starts, the first cycle afterwards is
/already/ too late to put audio into the output buffers !
Therefore I can think of only about three solutions:
1) Use the Jack slow-sync feature to /delay/ the transport start,
while we output a small 'pre-start' audio segment.
(This is the mechanism I was considering for revival of the
*count* *in* feature! )
However this seems a no-go because if another Jack client were
to also use the slow sync feature (we do for our wave cache!)
it would surely interfere with our latency correction and/or
count-in bar if it delayed the transport longer that we needed to.
2) Simply 'chop-off' the first small period of wave playback audio
(or midi) and proceed from there. After that everything
should line up. You are technically starting the wave from its
second segment in this case, but transport frame is still zero.
It's just, well you miss that first small segment. And this
would not work for a count-in bar, which is much longer.
3) Same as 2) but instead of chopping off the first segment,
lump it in with the second. This might be OK for midi
playback latency correction (at least we get all the events,
but they're bunched together). But audio? Meh... It would
sound like a glitch.
Perplexing. I may need advice on Jack or LAD lists.
Or find some fine literature.
Tim.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
