2018-01-30 9:00 GMT+01:00 Robert Jonsson <[email protected]>:
>
>
> 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.
>>
>
cool!
>
>> 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.)
>>
>
Do you mean that the mentronome always sounds late, in relation to an audio
track on the same output?
Shouldn't be to hard to verify by recording muse's output with a click
track on the audio track and the metronome playing.
IF that is the case shouldn't we simply trigger the metronome a buffers
time early or something like that?
>
>> 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'm confused, if it's the same with recorded audio doesn't that mean
everything is actually in sync?! Just delayed by the output buffers.
If you are trying to compensate while doing live monitoring through muse
things will never be perfect, that much I'm sure of. Your own sound will be
input+output buffers late while the recorded stuff only goes through the
output buffers. The only way to solve that is to monitor yourself directly,
outside muse (so called zero-latency monitoring) and compensate the
recording for the input buffers, as you've added now.
Make sense or am I barking up the wrong tree?
Robert
>
>> 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
