LIVE 9 : PDC IMPROVED OR NOT ?

[paulmaddox]

Come on Ableton, please fix these issues!

That. The lack of response to this thread seems like it may be telling though

[theophilus]

I don't know if they'll fix it, it seems that it was a design decision from the getgo for lower latency.

I do not believe the PDC automation issue has anything to do with trade-offs, there has been some debate about this live vs producer modes thing, but I don't believe that is necessary, I don't think they haven't made a decision to choose something over PDC automation, they simply haven't completed their automation feature to correct its timing..

of COURSE there are tradeoffs... i've been thinking more about how this should be implemented, and it's not clear to me that it's easy at all.

as some have noted, pdc affects all tracks... if i have 10 tracks, all blank, and insert a device with a delay of 64 samples on track 9, to get all the tracks to line up, I have to insert latency into all the other tracks too... whether track 9 is moved 'earlier' or the rest of the tracks delayed 'later' is kind of just semantics in playback (non-live) mode, but in general all the tracks have to move. if I go drop another 64 sample delayed device after it on track 9, now all the other tracks have to be delayed by 128 samples to catch up. So far, nothing earth-shattering, it just has to be done.

This is fine when using in 'studio' mode. What do I do if I have synths on the 10 tracks, blank, and then WHILE IT'S PLAYING (say, during a LIVE set) I decide to drop in a device with 64 samples of latency? All the other tracks should be delayed by 64 samples... but they're already playing, i can't just drop in 64 samples of silence. And I can't necessarily move the other track earlier either - i could 'jump' 64 samples and catch up, but that would cause a glitch too. The midi/automation has to move too - it isn't just the audio.

IOW, PDC works by looking the latencies of all tracks, and inserting delays so they all have the longest latency. Automation then gets delayed by the same amount. So, the PDC model tries to line up the 'ends' of all the tracks.

But this isn't the only issue - there are some things that live just can't help you with... if I twist a knob on a synth, and it's going through devices that cause 128 samples of latency (maybe excessive, just an example), I'm not going to hear that change until 128 samples later. And live, I don't want to be messing with the latencies later - I'll move the knobs based on what i'm hearing, with whatever latency is built-in to the system, and so the playback will be in time with that. This is not any different, really, from the general problems people have always had with music - whether it was the latency built-in to midi synths for hardware, or high buffer sizes required with early VSTs and sound cards. latency just doesn't get along with live performance, whether it's coming from hardware, software, or vsts.

I think they intended live to be played like an instrument, though meticulous programming is possible.

A separate producer vs. live mode makes some sense though. You will get pops, silence, something when modifying tracks, but that's ok (i think most apps i've seen mute the audio while 'catching up') for in the studio. It might make some people upset when they try to use studio mode live, but them's the breaks - i think they may already even have a studio mode built-in, as some have mentioned these problems magically mostly go away when rendering. so they would just need to enable it.

and i don't think people would care so much if it weren't for all the power live gives you for sound design with the racks etc. that makes you want to automate in live as well... otherwise people would just bounce to audio and mixdown somewhere else. it's not that easy to do when you've got tons of sidechained effects embedded into the track.

[glitchrock-buddha]

Well I'm certainly glad I've never gotten attached to any plug-ins with significant latency. The highest one I have is Amplitube 3, which reports 0.2 ms of latency, which won't cause a problem (and it's not like you'd add more than one instance on a track).

So if I understand correctly, having a latency inducing plug-in before a time based plug-in will make the time-based one trigger it's grid earlier than what the signal is sending it (since it was delayed). This appears to be what the volume shaper example was showing. The audio is sent after the volume shaper begins. So if you had something like effectrix, triggering an effect on the grid,it may trigger effects earlier than the corresponding sound at that point of the timeline. Similarly automation would happen just before the audio signal actually happens.

So I guess this is the same for plug-in instruments with latency? Most don't have latency but I picked up Aalto recently which does have about 6ms latency. So I guess any automation I do will be 6ms ahead of audio sent from Aalto. Does it just affect the track where the latency plug is located or all tracks? This is where it confuses me. I was under the impression that if my Aalto track has 6ms latency, that all other tracks would be delayed 6ms. And the automation would be delayed 6ms too. Is this not the case?

[petit nuage]

interesting thoughts about the oversampling delay 's issue in daws and oversampled plugs ... and tips to workaround :
http://forum.renoise.com/index.php?/top ... n-renoise/

this issue seems fixed in live 9's eq8 and maybe all the oversampled native plugs , so THATS REALLY NIIICE !!
im really not an expert so maybe i dont have understand something so ... one question : this issue seems linked to the way some plugs are programmed...

if live 9's new eq8 is optimized to fix that issue internally, i would like to know what about 3rd party plugs if they are not optimised for that ?

maybe just using high sampling rates ...but if the plug dont have an on/off oversampling mode by exple ?
is the latency still here even at high sample rate ?

[theophilus]

interesting thoughts about the oversampling delay 's issue in daws and oversampled plugs ... and tips to workaround :
http://forum.renoise.com/index.php?/top ... n-renoise/

wow andy gets around

if live 9's new eq8 is optimized to fix that issue internally, i would like to know what about 3rd party plugs if they are not optimised for that ?

oversampling is USUALLY a way to get around aliasing issues, and will always have latency. from what iirc (which might not be 100% right) andy redesigned the EQ8 filters in HQ mode so that they wouldn't alias, and therefore no longer need the oversampling (and don't have latency). so live isn't doing anything special for these, the devices themselves no longer add latency.

obviously this won't help third party plugs at all, and i don't know what other third party plugs are also capable of this trick.

[sdfak1234]

of COURSE there are tradeoffs... i've been thinking more about how this should be implemented, and it's not clear to me that it's easy at all.

as some have noted, pdc affects all tracks... if i have 10 tracks, all blank, and insert a device with a delay of 64 samples on track 9, to get all the tracks to line up, I have to insert latency into all the other tracks too... whether track 9 is moved 'earlier' or the rest of the tracks delayed 'later' is kind of just semantics in playback (non-live) mode, but in general all the tracks have to move. if I go drop another 64 sample delayed device after it on track 9, now all the other tracks have to be delayed by 128 samples to catch up. So far, nothing earth-shattering, it just has to be done.

This is fine when using in 'studio' mode. What do I do if I have synths on the 10 tracks, blank, and then WHILE IT'S PLAYING (say, during a LIVE set) I decide to drop in a device with 64 samples of latency? All the other tracks should be delayed by 64 samples... but they're already playing, i can't just drop in 64 samples of silence. And I can't necessarily move the other track earlier either - i could 'jump' 64 samples and catch up, but that would cause a glitch too. The midi/automation has to move too - it isn't just the audio.

IOW, PDC works by looking the latencies of all tracks, and inserting delays so they all have the longest latency. Automation then gets delayed by the same amount. So, the PDC model tries to line up the 'ends' of all the tracks.

But this isn't the only issue - there are some things that live just can't help you with... if I twist a knob on a synth, and it's going through devices that cause 128 samples of latency (maybe excessive, just an example), I'm not going to hear that change until 128 samples later. And live, I don't want to be messing with the latencies later - I'll move the knobs based on what i'm hearing, with whatever latency is built-in to the system, and so the playback will be in time with that. This is not any different, really, from the general problems people have always had with music - whether it was the latency built-in to midi synths for hardware, or high buffer sizes required with early VSTs and sound cards. latency just doesn't get along with live performance, whether it's coming from hardware, software, or vsts.

I think they intended live to be played like an instrument, though meticulous programming is possible.

A separate producer vs. live mode makes some sense though. You will get pops, silence, something when modifying tracks, but that's ok (i think most apps i've seen mute the audio while 'catching up') for in the studio. It might make some people upset when they try to use studio mode live, but them's the breaks - i think they may already even have a studio mode built-in, as some have mentioned these problems magically mostly go away when rendering. so they would just need to enable it.

and i don't think people would care so much if it weren't for all the power live gives you for sound design with the racks etc. that makes you want to automate in live as well... otherwise people would just bounce to audio and mixdown somewhere else. it's not that easy to do when you've got tons of sidechained effects embedded into the track.

Before writing 8 paragraphs, you may want to actually read what you're quoting. First of all, who said there were no tradeoffs?? that's not what I said.. also who said it was easy?? read what was said carefully and don't respond with capitalized letters unless you've actually got a point that needs to be shouted.. your response is actually quite condescending and even more so, since you're completely off the mark. I thought the way you were writing you were about to drop some knowledge on us, but instead you simply rehashed old, well understood PDC problems. What you've gone and done here is write a lengthy explanation about plugin delay compensation as it stands, we are clearly talking about plugin delay compensation for AUTOMATION, automation is not being compensated - why would you need a mode to correctly compensate written automation?. You've also gone on to write about this live mode vs producer mode thing with no explanation for why you'd need such a feature.. I think you are talking about a mode for audio latency, that is not what we are talking about... and I still don't believe a mode is even needed for that, your explanation did not swing me... I also have to say that regardless of the problem at hand, this is a problem that has been tackled by Ableton's competitors. For the record, I do not have a problem with the way Live currently handles audio delays whether it's playing live or not, I am concerned about how compensates the automation for these plugins and unfortunately your clever explanation has no bearing on such a problem.

[su]

step lightly. king of threads is in da hizzy

[sdfak1234]

also before we get this discussion even more diluted, can we move talk about oversampling to a new thread? I'd rather this one stick to PDC.

[sdfak1234]

I want to hear from Ableton about how 'hard' this problem is. It can only be worded in the form of an excuse, I do not believe someone can argue that PDC on automation is a fix that requires several years of development. I actually find it crazy that people attempt to rationalize this rather than blame Ableton for screwing up... as I said before, this PDC on automation issue is indefensible, inexcusable, it's been a long time and I have heard no logical reason as to why this would be so difficult to implement.

[Tone Deft]

[sdfak1234]

This would be really funny, and make a little bit of sense of we actually wanted it now.

The reality is that we wanted it a long time ago.. and some would argue this is a need, not a want. So replace "I want it now" with "I needed it 5 years ago".

[H20nly]

fixed.

[theophilus]

What you've gone and done here is write a lengthy explanation about plugin delay compensation as it stands, we are clearly talking about plugin delay compensation for AUTOMATION, automation is not being compensated - why would you need a mode to correctly compensate written automation?. You've also gone on to write about this live mode vs producer mode thing with no explanation for why you'd need such a feature.. I think you are talking about a mode for audio latency, that is not what we are talking about...

fair enough. apologize if it sounded condescending, didn't mean it that way. but audio latency IS automation latency... they are tied together. audio latency = how far the audio is from the original control signal that caused/modified it. when you insert that 64 sample device, you are ALSO adding a 64 sample delay between your automation curve and its effect. they are one and the same thing.

it's not that hard really, but it does have live impacts - any time you add or remove something to the set, to do it properly, you may need to recalculate delays for every track and device in the system. i think the live method limits the impact to just the track, at the exchange of having everything possibly out of sync. maybe not a good tradeoff, i don't know.

honestly, i think it's just that their current model only has a track delay, and they really need a delay for every device. that doesn't seem impossible.

[Tone Deft]

This would be really funny, and make a little bit of sense of we actually wanted it now.

The reality is that we wanted it a long time ago.. and some would argue this is a need, not a want. So replace "I want it now" with "I needed it 5 years ago".

how about you got your answer 5 years ago and an update last week? henke's been quoted as saying they made a conscious decision years ago to not go that route.

totally wrong time for your rant-fest. think about it. they just released a new version, this is the WORST time for feature requests, not to mention the wrong forum, not to mention that they've disavowed the forum from their site. their engineers are either taking vacation or wholly fixed on bugs, new features? no way.

they've known that users want this, they've put ZERO effort into putting it into the software. Live will not have PDC, end of story, game over.

[sdfak1234]

This would be really funny, and make a little bit of sense of we actually wanted it now.

The reality is that we wanted it a long time ago.. and some would argue this is a need, not a want. So replace "I want it now" with "I needed it 5 years ago".

how about you got your answer 5 years ago and an update last week? henke's been quoted as saying they made a conscious decision years ago to not go that route.

totally wrong time for your rant-fest. think about it. they just released a new version, this is the WORST time for feature requests, not to mention the wrong forum, not to mention that they've disavowed the forum from their site. their engineers are either taking vacation or wholly fixed on bugs, new features? no way.

they've known that users want this, they've put ZERO effort into putting it into the software. Live will not have PDC, end of story, game over.

Totally wrong time for my rant-fest?? what are you talking about?, this "rant-fest" is in reaction to not getting the fix, it isn't a feature request??? obviously...the feature has been requested.. a couple of weeks ago was the first word we ever got on Live 9.. so how were we supposed to rant about it before knowing it hadn't been fixed? bare in mind Ableton haven't even admitted it officially... you are really pulling at straws with your opposing arguments. You're completely wrong about who said what years ago and what route they are going... actually it was posted in Jan 2011 that they are working on the problem and that it was high on their list. I believe that's been brought up in this thread or the other PDC thread.

I have also said previously on this subject that I believe the reason why it hasn't been fixed is because there is low awareness of understanding of the ramifications of the issues and now that we know it hasn't be implemented in the long awaited version 9, I believe now is a perfect time to rant about it.