LIVE 9 : PDC IMPROVED OR NOT ?

[simpli.cissimus]

Fanboys...pfft...!

[Tone Deft]

to people searching best workarounds:

ive been really affected by pdc issues for a long time now and i spent lot of time searching workarounds.
i found no nudging/delaying system decently possible and imo bouncing each insert point is a nightmare and killing creative process/modularity, not to mention disk space.

so the 'i found best' workaround that remain "not cool, but doable" is to realign each concerned automation in case of hearable drift/latency by 'rolling' the play header.

basically set the automation/modulation to loop

ie if you are gating each beat on a bar and hear a drift that fu8cks attacks, display modulation, disable snap and move the playing header to the end of the loop (only on automation lane, clip/midi notes remain normal), and slowly offset it back until audio result work as expected. this mean the start of 'normal' automation will be later compared to grid, and as audio as been delayed man can find the needed amount so that both will match again as they would if was properly compensated.(= 'roll' of the amount of latency)

then man is still able to draw modulations/automs/keep previously done/ snapping on grid as usual. (btwn this won't correct the fact midi timing infos of plugins will still be out of sync, but at least man can manually correct ie messed attacks caused by modulations/automation).

quite boring if you had ie 50 clips with 5 automs to realign caused ie by a new drop of vst with latency, but in few case this is still doable and works...

sounds like a lot of wasted time using the wrong DAW.

[fx23]

nope, because exept pdc issue and the automation to session/clip compatibility flaw they now atlast fixed, i still find live to be the best by far for my needs.

and well, there wasn't any descent challenger with session for this decade

if bitwig claim to have a 'working as expected pdc', i ll give a shot, but half of my sounds are done on operator so.. i would prefer ableton to fix it before i die.

[Sage]

But may I ask you, if you think it's O.K. to give up the freedom to use any effects you want ?
Where is the sense in that ?

What a stupid question. There are plenty of scenarios where you have to give up using certain effects, understanding what is appropriate in any situation is part of being an engineer/producer/mix or master engineer. Even as a guitar player, I take what I need for the task in hand, not everything so I have the freedom to do whatever I want.

[theophilus]

Sorry..., but we didn't understand each other well...!
Adding many delays in one row isn't what I mentioned.
Do not use a Drum-Rack, make one combined Instrument-Rack with more layers.

sure, instrument racks could be different from drum racks. and maybe there is an issue if grouped.

i do want the single volume shaper at the end; ideally, even at the end of all these crazy chains, we should not have any automation delay/midi out of sync. if it's true there, it's true down the chain too.

so, as a follow-up, i did something like this, posted a picture on the ableton beta forum (because i did this in 9), with an instrument rack with a couple of chains, with one of the chains having an audio fx rack, with another audio fx inside it because i grouped a bunch of simple delays... and even this complex chain was perfectly in sync at the end. maybe there is a bug with some particular more complex config, i'll try some other things, but it looks like with the internal effects, live is doing this correctly, both audio and midi sync.

i did see one weird issue which i'm not sure what it is, and is more concerning, where the first beat of the bar actually changed on the second loop (and stayed changed), though no effect on the rest of the bar. still looking at that one.

there's no way ableton can keep in sync with an effect that is changing latency after load afaik... the effect would have to tell live that the latency changed, and i don't know if there's even an api to do that - i.e. all hosts are probably affected in this case. alternative would be to poll constantly every effect in the system to see if it's latency changed... i don't know what the overhead would be in that case, but requiring a disable/enable to recalculate latency seems reasonable in that case...

[Sarrova-Q]

If it's impossible to fix PDC because of the way Live is build, would it be possible to fix it like this:

• Have some sort of 'helper device' - let's call it 'Latency Checker' or LC within Live's native audio plugins with an IN and OUT version.
• LC IN needs to be placed at the beginning of your rack, LC OUT ath the end.

This way:

AUDIO (plugin or wav) ---- > LC IN --- FX RACK1 --- FX RACK2 --- PLUGIN X --- PLUGIN Y --- LC OUT --- > audio out to master
The LC OUT device would be linked with the LC IN device and 'measure' the latency between the two.
You can then, manually, correct the amount of milliseconds delay.

Just thinking out loud, don't even know if that is possible.
But it would mean no extra stress for the cpu (you can delete the LC devices after correcting the latency and they do nothing else than measuring the latency so they should be light on cpu anyway), no complete redesign of Live (if the LC devices are possible) and always be sure everything is tight.

Also, when changing plugins order or putting racks inside racks and parallel racks (live is very complex that way) it should make no difference as the two LC plugins just measure everything between them.
No?

[theophilus]

it should all be fixable, EXCEPT the case mentioned where you do something in the plugin itself that changes the latency while live is running.

if, for example, you are using a vst compressor, and change it from a non-lookahead mode to a lookahead mode. that should change the latency of the device: it should get longer by the amount of lookahead. however, afaik there's no way for the device to poke live and say 'hey, my latency changed, you should go do something'. and live assumes parameter changes don't change latency (since recalculating PDC is expensive and most parameter changes don't change latency).

maybe internal live devices do something like this, i don't know (will have to try it later). other alternative is that live could constantly poll each vst device for its latency, but that may take a lot of CPU as well for dubious advantage.

every other case should just be an extension of the audio PDC that live is already doing (correctly as far as i can tell).

[Sarrova-Q]

it should all be fixable, EXCEPT the case mentioned where you do something in the plugin itself that changes the latency while live is running.

if, for example, you are using a vst compressor, and change it from a non-lookahead mode to a lookahead mode. that should change the latency of the device: it should get longer by the amount of lookahead. however, afaik there's no way for the device to poke live and say 'hey, my latency changed, you should go do something'. and live assumes parameter changes don't change latency (since recalculating PDC is expensive and most parameter changes don't change latency).

No, I think you misunderstood.
I know that isn't possible.

My idea was that when you change something (like 3ms lookahead), the only thing that changes is a different readout of the LC OUT device (it would say 12 ms instead of 9 for example).
That's the whole plan, Live doesn't need to change anything, you just check each track with the LC devices and correct the delay manually.

That would be more reliable than plugins reporting latency and Live automatically compensating (some plugins are even giving wrong latency values).
If these LC / ping devices work, you can always trust these (it would mean an exact value of the latency as it measures the latency between the two LC devices without needing to know anything from the plugins in between. You can then manually change the track delay.

[theophilus]

it should all be fixable, EXCEPT the case mentioned where you do something in the plugin itself that changes the latency while live is running.

if, for example, you are using a vst compressor, and change it from a non-lookahead mode to a lookahead mode. that should change the latency of the device: it should get longer by the amount of lookahead. however, afaik there's no way for the device to poke live and say 'hey, my latency changed, you should go do something'. and live assumes parameter changes don't change latency (since recalculating PDC is expensive and most parameter changes don't change latency).

No, I think you misunderstood.
I know that isn't possible.

My idea was that when you change something (like 3ms lookahead), the only thing that changes is a different readout of the LC OUT device (it would say 12 ms instead of 9 for example).
That's the whole plan, Live doesn't need to change anything, you just check each track with the LC devices and correct the delay manually.

That would be more reliable than plugins reporting latency and Live automatically compensating (some plugins are even giving wrong latency values).
If these LC / ping devices work, you can always trust these (it would mean an exact value of the latency as it measures the latency between the two LC devices without needing to know anything from the plugins in between. You can then manually change the track delay.

not sure how the plugin would know? theoretically, you could have LC1 send an impulse through the rest of the chain and then see how many samples it takes LC2 to see non-zero, something like that, as long as they both have some master reference to measure against (which, because live doesn't currently compensate midi sync, you can measure against the master midi timeline i guess).

it would definitely be useful to have some idea of what kind of latencies you are seeing in your set... just seeing that when you drop device X in your set, a lot of numbers change, would be useful information.

can't fix automation offsets though. could sort of fix midi sync offsets, but because you can only add latency, not subtract it, you might have to add up to an extra full bar of latency to compensate...

[Sarrova-Q]

not sure how the plugin would know? theoretically, you could have LC1 send an impulse through the rest of the chain and then see how many samples it takes LC2 to see non-zero, something like that, as long as they both have some master reference to measure against (which, because live doesn't currently compensate midi sync, you can measure against the master midi timeline i guess).

it would definitely be useful to have some idea of what kind of latencies you are seeing in your set... just seeing that when you drop device X in your set, a lot of numbers change, would be useful information.

can't fix automation offsets though. could sort of fix midi sync offsets, but because you can only add latency, not subtract it, you might have to add up to an extra full bar of latency to compensate...

Mhhhyeah I see. I had the idea looking at Presonus Studio One's impulse device for working with external hardware ...
Just want to find a solution that is 1 reliable AND 2 doesn't take too much time to make (I'd hate waiting another 3 years to get tight, perfect latency compensated, in your face audio when mixing on large projects ... )

[fx23]

Having a device that computes latency is a nice idea but im afraid it wont help that much..
Lets say it works and it reports you that at this insertpoint there is a 1024 samples latency, what would we do then? Nudging/delaying that track of this amount wont fix the automation itself but will shift booth audio and automation with drift. Afaik the only way to correct is either to shift automation curve or offset its playing header. If the thing was able to convert samples to beat duration then we could offset playing header of same amount, but if so i guess it could do it directly and automatically..

I understand the device and chain analysis and tracking latency is a huge task, but by waiting there could b a first semi manual solution. the way i see, a new 'automation offset/roll' value avaible. Like tracks have, but this would be for automations, and per device. Ie selecting an automation/ modulation lane in a clip would display a new editable "device offset" value we could adjust and it would delay autom of that value. This way man can fix in one shot all automations of a device, and then, once they will have finished the complete more advanced tracking stuff this value could automatically be filled by pdc and no more manually.

[H20nly]

But may I ask you, if you think it's O.K. to give up the freedom to use any effects you want ?
Where is the sense in that ?

What a stupid question. There are plenty of scenarios where you have to give up using certain effects, understanding what is appropriate in any situation is part of being an engineer/producer/mix or master engineer. Even as a guitar player, I take what I need for the task in hand, not everything so I have the freedom to do whatever I want.

you're out of control Sage!

you do realize that music is meant to be absomuthafukenlootly perfect and that anything less than ideal conditions in which every conceivable option is available all the time will not allow the creation of great music, right?

you're clearly not a Pro.

[simpli.cissimus]

But may I ask you, if you think it's O.K. to give up the freedom to use any effects you want ?
Where is the sense in that ?

What a stupid question. There are plenty of scenarios where you have to give up using certain effects, understanding what is appropriate in any situation is part of being an engineer/producer/mix or master engineer. Even as a guitar player, I take what I need for the task in hand, not everything so I have the freedom to do whatever I want.

I'm sure you think you know what is right !

Thanks for your input...

[H20nly]

[simpli.cissimus]

..................