[LAU] Session management with NSM

[Rui Nuno Capela]

On 09/03/2014 10:17 PM, Ralf Mardorf wrote:
> On Wed, 2014-09-03 at 21:06 +0000, Fons Adriaensen wrote:
>> On Wed, Sep 03, 2014 at 10:43:35PM +0200, Ralf Mardorf wrote:
>>> On Wed, 2014-09-03 at 20:38 +0000, Fons Adriaensen wrote:
>>>
>>>> Which, if true, would only mean that Qtractor does its latency
>>>> compensation the wrong way. Note the 'if true'.
>>>
>>> For the versions of Qtractor I used it is true. An issue for me, because
>>> I like to be able to use different latencies, at different work stages.
>>> I'm aware that Ardour's latency compensation is smarter. But IMO it's
>>> important, that Linux users who prefer session managers, at least get
>>> informed about such issues, what ever applications they use.
>>
>> There's nothing smart about it, it's not rocket science.
>>
>> If Li and Lo are the current input and output latencies, then
>>
>> * When recording a track, adjust the logical postion (the start offset
>>    relative to whatever the session uses as reference) of the data by Li.
>> * When playing a track, adjust its logical position by Lo.
>>
>> This will do the right thing, even when period sizes etc. change.
>>
>> And a session manager should not try to compensate for design errors
>> in applications. Once you start to do that, there is no end to the
>> amount of misery you will cause.
>>
>> Ciao,
>
> Rui likely should know more about Qtractor's current abilities, than I
> do.
>

qtractor does try to adjust the so called logical position or start 
offset by Li as Fons explained; the Li (input latency) value is the one 
given by jack_port_get_latency_range() at the time capture/recording 
takes place; the actual offset is however quantized/rounded to MIDI 
resolution (in ticks per quarter-note or beat)--this fact alone might 
add to its "strangeness" i guess.

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc at rncbc.org