2018-01-30 5:10 GMT+01:00 Tim <[email protected]>:
>
>
> 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.
>>
>
Just realized it wasn't in the release, added it afterwards, so, less panic
can be had..
>> 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.
>
> And of course I can't recreate it now... a few weeks ago it was repeatable
in some song, which I of course can't remember which.
>
> 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.
>
Hmm, I'll try to get back to this tonight see if I can get my head around
how that can be.
/Robert
------------------------------------------------------------------------------
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
