![Laughing :lol:](./images/smilies/icon_lol.gif)
![Laughing :lol:](./images/smilies/icon_lol.gif)
![Laughing :lol:](./images/smilies/icon_lol.gif)
sounds like a lot of wasted time using the wrong DAW.fx23 wrote: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...
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.simpli.cissimus wrote: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 ?
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.theophilus wrote:sure, instrument racks could be different from drum racks. and maybe there is an issue if grouped.simpli.cissimus wrote: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.
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.
No, I think you misunderstood.theophilus wrote: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).
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).Sarrova-Q wrote:No, I think you misunderstood.theophilus wrote: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).
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.
Mhhhyeah I see. I had the idea looking at Presonus Studio One's impulse device for working with external hardware ...theophilus wrote: 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...
you're out of control Sage!Sage wrote: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.simpli.cissimus wrote: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 ?
I'm sure you think you know what is right !Sage wrote: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.simpli.cissimus wrote: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 ?