option "StrictDelayCompensation" ??? what is that doing?

[3phase]

"StrictDelayCompensation"

This disables Live's play-through optimization.

When delay compensation is on, don't play-through optimize (favor exact sync over low latency).

Example: -StrictDelayCompensation


Question:

what do the reffer to as exact sync? the placement of the notes as you played them? ..so by default they placement is what ever it wants to be but you have a low latency?


is that right?

[3dot...]

pasted from another thread...

Live has a so called "playthrough optimization" which disables the plugin delay compensation for all tracks that are record-ready or have the "Monitor" switch set to "IN". The reason is that we assume that you want to play a software instrument (or resp. monitor an audio input) with the lowest possible latency. In other words, you will only get the latency of your audio interface + the latency of the actual plugin device instead of the overall latency of the entire project.

We have a hidden option which can be enabled via the so called "options.txt" file. This option will deactivate the playthrough optimization, so all tracks will be compensated regardless of their monitoring settings.

[3phase]

pasted from another thread...

Live has a so called "playthrough optimization" which disables the plugin delay compensation for all tracks that are record-ready or have the "Monitor" switch set to "IN". The reason is that we assume that you want to play a software instrument (or resp. monitor an audio input) with the lowest possible latency. In other words, you will only get the latency of your audio interface + the latency of the actual plugin device instead of the overall latency of the entire project.

We have a hidden option which can be enabled via the so called "options.txt" file. This option will deactivate the playthrough optimization, so all tracks will be compensated regardless of their monitoring settings.

but this is not explaining what the benefits are when disabling this playthru optimisation..

and actually all a very funny thing anyway.. other companys have even allmost latency free midi thru without suc gimmicks..

i wonder if the function effects the precision of the recording because live is sometimesdoing dreadfull things on the midi notes you play in.. "better sync" when playthru optimisation is off" better sync to what? to musical played reality?

[crumhorn]

That is well worth knowing!

It's the first useful thing I've seen around here in weeks!

[crumhorn]

The relationship between this and the delay compensation added to recorded events (to compensate for monitoring latency) does seem a bit confusing.

I would hope that the behaviour would be consistent. eg when motitoring is off it records the events as soon as they occur; with monitoring on the monitoring delay should be increased in line with this new "strict" delay compensation - if it is enabled.

[3phase]

The relationship between this and the delay compensation added to recorded events (to compensate for monitoring latency) does seem a bit confusing.

I would hope that the behaviour would be consistent. eg when motitoring is off it records the events as soon as they occur; with monitoring on the monitoring delay should be increased in line with this new "strict" delay compensation - if it is enabled.

really? so you have perfect midi recordings when you dont hear what you play but screwed ones when you play an expander? but this only with or without the option?

i guess the ableton people dont know themself otherwise it would be dokumented somehow..or they are a bit ashemed about the implementation and dont talk much about it?

so we need to measure that? how do we measure such a thing?

we syncronise the appearance of a midi note on event with an audio click with the aid of an oscilloscope on the nord g2... record this into ableton and compare the time position of the audio and midi event in the recording?

but how do we get the time position.. ableton dont gives any time info that is precise enough in the audio clips .. arrange zooms ? maybe thats at least enough to see wether the placement is precise... but than again..such midi placement issues are not consistant in live..sometimes it works better..sometimes its really screwed and you need to relaunch the program to get it wright again.. .. oh oh

ok.. back to logic setup..its a hard piece of work.. but once done it safes time..

i just started to understand again why logic is not popular with beginners...beginning with it is quite a task.. even for somebody that has spend half its livetime with it...

but at least it performs stable.. it just crashes from time to time.. but the performnce and soundquality is stable and predictable..

[sanosdole]

Does anybody know if this also applies to internal audio routing (e.g. bus style routing)?

I still do not really understand how this "play-through" optimization works.

In other words, you will only get the latency of your audio interface + the latency of the actual plugin device instead of the overall latency of the entire project.

How does this perform when the monitoring track is routed to another track monitoring?

[3dot...]

the default playthrough optimization :

if a track is in monitor/rec mode.. lateny compensation is only for the interface latency...

with "strictDelayCompensation" your monitored/rec enabled tracks..
compensate for the whole live set'(including all plugins) latency..

(if I understand correctly..)

[3phase]

the default playthrough optimization :

if a track is in monitor/rec mode.. lateny compensation is only for the interface latency...

with "strictDelayCompensation" your monitored/rec enabled tracks..
compensate for the whole live set'(including all plugins) latency..

(if I understand correctly..)

but how does that relate to the note placement along the timeline..

and what is better to avoid jittred recordings?

sometimes life places the midinotes like a drunk.. is that an unrelated bug or something that can be optimized with this playthru optimisation?

[crumhorn]

It's possible to test Lives latency and jitter by routing events generated in live back into live via midi yoke or equiv on mac. any difference between this and using a physical interface is due to the physical interface and device driver software.

I did some tests like this ages ago, I'll see if I can dredge up the results. As I recall it depended heavily on the interface being used. The interface/drivers on my old FW410 sometimes delivered events in the wrong order(!!!) if if remember right.

[crumhorn]

OK. from this ancient thread -> http://forum.ableton.com/viewtopic.php?f=1&t=130241

These tests were all done with monitoring turned off to try and measure the effect of PDC on MIDI timing. So Live should record exactly what is received from the device drivers (according to Ableton).

The results are weird, with some of the recordings being ahead of the original.

Would be interesting to collect results for different hardware, operating system and driver combinations if anyone can be bothered.

For the sake of sheer geekishness I just did some Loop Back MIDI timeing tests on my FirePod using Live.

This is on a 2GHz dual core PC laptop running vista.

Basic method:

set record quantise off.
create one bar midi clip on track 1 with a few chords exactly on the beat.
send output to FirePod with MIDI out looped back to MIDI in.
set track 2 to record, monitor off.
global quantise = 1 bar.
launch the clip on track 1 then launch recording on track 2 for a bar or two.
build a nice collection of recorded clips with different settings.
For comparison some recordings were done via MIDI Yoke.

Variables:

FirePod MIDI or MIDI Yoke
Delay Compensation on/off
MME or DirectMusic
FirePod ASIO driver @176 samples or SonicReality (built in soundcard) ASIO driver @2000 samples

In the image:

the first track (white) is the original midi being sent out.

The next two tracks - MYFP and MYSR - are using MIDI Yoke and the FirePod / SonicReality - Delay compensation had no effect on this setup and using DirectMusic with MIDIYoke severely mangled the data.

All remaining tracks are recorded via the FirePod's MIDI interface.

Tracks 4 - 7 use MME and tracks 8 - 11 use Direct Music
Tracks 4, 5, 8 and 9 were recorded with the FirePod ASIO driver selected
Tracks 6, 7, 10 and 11 were recorded with the SonicReality ASIO driver enabled.
In each pair of tracks with the same colour the second one has Delay Compensation turned on

Here are the results


It seems that time travel is possible after all!

Look at the bottom of the picture to see the time in minutes, seconds and thousandths.

Scroll to the right because the note off timing is interesting too.

I'm not sure what conclusions can be drawn from this except that ableton must be doing some interesting adjustments behind the scenes, and that getting the right combination of settings can make quite a difference to the result.

Edit - further thoughts...

The notes recorded via DirectMusic are probably adjusted by Live to reflect the Time Stamp from the hardware. This probably has little relation to the actual MIDI delay, since clearly a message can't possibly be recieved before it is sent. Either the time stamp must be wrong or Live is overcompensating in some way.

The notes recorded via MME driver without Delay Compensation probably give a better indication of the actual delays.

It seems bizzar that the choice of ASIO driver affects the MIDI timing so much. I'm sure that if I could understand this then I would know a lot more about audio software than I do now.

[Khazul]

I would guess this really comes into play when you have (for example) two tracks -
A. Audio track wth a heap of high latency plugisnnint it - let say the total is 10ms - ie enough to be annoying when playing added to the audio interface latency etc.
B. A soft synth and otherwise low or zero end to end latency.

If both tracks are routed to the same mix point (master track usually, or perhaps a submix), then when both are in playback, track B will be delayed by 10ms to compensate for the latency of the plugins in Track A so that the audio samples from both tracks arrive exactly in sync and so are summed correctly. (If lives summing is broken in any way - this is the problem - relative timing of data arrival into summing NOT quality of the calculations - 3phase - take note - if you think about it properly - you already know this!).

Now StrictDelayCompensation should (I assume) affect track B as follows when it is rec-enabled:
StrictDelayCompensation Off - the 10ms delay normally on this track during playback is switched off so that what you play is as close as possible (time wise) to what you hear.
StrictDelayCompensation On - the 10ms delay normally on this track during playback is left on, so what you play into Track B gets delayed by 10ms (but this does not affect record timing into this midi track).
Note - this has no bearing at all on midi processing quantization where midi events are effectively quantized to audio buffer cycles times - simply because thats how live appears to work - audio interface says it needs a buffer fill, so live calculated all audio and polls the midi interfaces.

Things of course get more complex when you consider a typical EDM production wit a heap of sub mixes and cross track routings for compressor sidechain and buffer deferrals resulting from deliberate or accidental return feedback loops etc.

Live does this get this all wrong sometimes when some 3rd part plugins are used, but not consistently - often reloading a set where the micro timing has gone to hell (you will sense this mostly as a loss of the nice groove you recorded/programmed across several tracks and especially if you messed with individual track delays to acheive i, but with really short latency compensation plugsin, it might just be slight phasiness, loss of punch and/or mid/high end artifacts). Anyone using IK T-Racks stuff has probably has this happen. at times - got a really nice groove programme, then during the course of whatbyou though where non timing related edits you suddenly realise the nice groove you had is now just flat and lifeless - timing is buggered time to quit and reload.

The other side is when you get you nice groove going when the timing was allready buggered and you didnt realise until you later load a track and wonder why you dont 'feel' it anymore. It may just be your groove was actually shit, but it could actually be because the reload fixed the timing bug in the set and so now you need to fix your set to compensate - you might be able to band-aid it by fiddling with track delays. Note - This mostly applies when you are making use of groove templates, small (<10ms) track delays and aggressive use of several compressors across different track to impact perceived timing and overall groove and get a tight result. Note - just because you hear this - it doesnt mean you have actually hit this bug - you might have simply fucked everything up yoursefl with a compressor or some otehr tweak. Thats why its such a pain - figuring out what went wrong and when/how etc takes alot of time.

This is the kind of shit I dont have to put up with in Cubase and Logic - but the raw audio engine summing quality when the timing is right in all 3 is just fine as far as I can tell and basically the same.


BTW - until this thread I didnt know this option existed, just aware of the behaviour, but now it explains so much. Shame it cant control Monitor-IN and Rec-Enable separately. Logic and Cubase do have similar options, but they are there in the preferences dialogs or as quick access buttons to enable/disable as needed.

[3dot...]

in short..
try to record with monitor set to 'off' ..
(unless you really NEED to monitor through Live..)

avoid sidechaining/internal routings until mixdown...if you can..

and...
leave it at default if you record soft-synths lines

[3dot...]

and that timing is a bitch in Live.. (but not so much in other DAWS?!)

[mr.ergonomics]

very interesting. I don't have to much time to contribute at the moment, but I appreciate the investigation! I have shown some PDC problems in the past too, so I'm happy with every good new example that shows ableton that there is a potential problem.

ps: that said, I suggest to test other daws too to a certain degree. I have also found that they are not always perfect too. I think it's important to have this in mind to get the right estimation of the problem.

pps: another small thing which may be interesting:

http://forum.ableton.com/viewtopic.php?f=1&t=163086

thanks for reporting back broc, I tested it again. It true that I get low jitter (most less then 1 ms, max 2 ms) when I record a midi signal from a external source (cubase to ableton). but as soon as I play midi in ableton and record it again via loopback I get a pretty big jitter (about 8-14 ms). the recorded note length was a bit shorter, but that may be a fault from midi source or my fault, will check that again.

ableton->out->in = big jitter
in->ableton =low jitter

so I think it save to say that just recording midi in ableton don't seem to be a problem under normal circumstances(didn't test high cpu load and stuff like that). that's good to see.