@ tone: you are right i don't need to be such cash, but beleive me
don't think a second they don't know that and are a bit 'shy' in their manual.
conspiracy is a strong word, i would just say false claims and lasy pgming.
Live + 3rd party plugins = FAIL
-
ninox_rufa
- Posts: 94
- Joined: Tue Apr 07, 2009 8:26 am
Re: Live + 3rd party plugins = FAIL
Sorry mate not possible:arafel wrote:Solution A: Turn off Delay Compensation.
Options > Delay Compensation (just uncheck it).
Then manually adjust tracks with Track Delay until they tighten up.
Done.
1. If you turn off delay compensation then you can no longer adjust a track's delay.
2. My first point doesn't even matter anyway
The sync problem affects audio WITHIN a track, not just how it compares to other tracks. For example as soon as you put one (non-zero) latency plugin in front of Beat Repeat, Beat Repeat is no longer repeating the piece of audio that it should. So even if you could adjust the track delay it doesn't fix the problem.Point is it doesn't sound good. I fully believe in trusting your ears. You might not notice it on one track but put a bunch of tracks that are all slightly out of time on top of each other and you will notice. If you limit the order of your plugs to avoid this issue there ain't much room left for creativity. Also I've found it doesn't have to be high latency plugins. And using sends does not make any difference to the problem.arafel wrote:Solution B: Alter plugins (reorder, use lower latency plugs, use sends instead, etc, etc) to bypass the problem where it exists or makes an audible difference.
Eg - if your swirly LFO modulated and crazy automated pad sounds awesome... then it is awesome. No worries if it is out of sync by xxx ms. Print it and make some more noize.
Remember if it sounds good it is good.
Try this example. It doesn't use phase cancelation.
1. Put a MONO drum loop on a track. Put Beat Repeat on it.
2. Duplicate the track so you have two tracks.
3. Pan the first track hard left.
4. Pan the second track hard right.
This means you should be hearing a mono signal yeh? The image is in the middle of your monitors.
5. Put one third party plugin on the second track in front of Beat Repeat (make sure it's off so it's doesn't colour your sound).
Straight away you'll notice a stereo effect. Duplicate that plugin again and the result gets worse. This is showing you that you've messed with the signal on that second track.
Try another:
1. Use just one track.
2. Put a drum loop on it.
3. Put Beat Repeat on it.
4. Add a third party plugin and duplicate it once (make sure it is turned off or if it has a wet/dry set it to dry).
You'll hear that Beat Repeat is now cutting off the attack on your loop, because Beat Repeat's 'action' hasn't been adjusted along with the audio.
If you don't hear this difference with just one or two plugins in front you're really lucky with your plugin choices because this is noticeable with every plugin of mine that I've tested so far and I'm sure some of them have to be low in latency.
I really wish there was a solution. There isn't.
Last edited by ninox_rufa on Fri Jan 21, 2011 1:23 pm, edited 1 time in total.
MBP 2.3GHz QCore i7 4GB | Ultralite mk3 | 10.7.4 | Logic Pro 9.1.6
Re: Live + 3rd party plugins = FAIL
yup exactly there are absolutely no possible workarble workaround for thoses issues.
automs/mod are out of sync relating audio properly compensated, adjusting track delay won't help. the only thing is to manually select automs and shift them,
wich is not possible do do each time your plug chain change on 500 clips and 2000 automations, and result is working out of grid = no snap.
same for the clock sync report, exept manual adjust that will only work on live devices that have precise offset feature, not the other, and not a single VST
that rely on vstcycletime/midi clock.
automs/mod are out of sync relating audio properly compensated, adjusting track delay won't help. the only thing is to manually select automs and shift them,
wich is not possible do do each time your plug chain change on 500 clips and 2000 automations, and result is working out of grid = no snap.
same for the clock sync report, exept manual adjust that will only work on live devices that have precise offset feature, not the other, and not a single VST
that rely on vstcycletime/midi clock.
-
LoopStationZebra
- Posts: 10586
- Joined: Sat Jan 17, 2009 5:57 pm
- Contact:
Re: Live + 3rd party plugins = FAIL
That is exactly right.ninox_rufa wrote:There is NO solution. Because of the nature of the problem there is nothing you can do.
Again, not sure how many of you read this guy's post over at IDM, but it really does explain it all quite nicely.
by "nopattern" (ignore all the other "which sounds better" junk beforehand).
http://www.idmforums.com/showthread.php?t=54715
I came for the 
But stayed for the
But stayed for the
Re: Live + 3rd party plugins = FAIL
Wow this nopattern post is impressive ! Is the guy on the ableton forum as well ?
Re: Live + 3rd party plugins = FAIL
I guess the biggest irony with this is that Live tends to get used by people trying to produce track with alots of hard tempo synced effects or hard cutting of sounds (via pumping, beatmashers, stutters etc) where automation and clock tightness is needed to avoid horrible glitches (unless doing minimal/idm etc).
In Cubase 6 where is all works pefectly, alot of folks are probbaly doing guitar band/accoutic etc where TBH it rarely matters because you are dealing with h=normnal human timing rather than precise machine timing anyway
I really dont want to have to use Cubase 6 for this kind of thing - while this version can cope with routing etc, it such a pain to set them up and edit vs the rapid simplicity of doing it in Live with its drag and drop etc that I just dont want to have to endure the likes of cubase more than nescessary.
These days stuff like this should just work without hacks, work arounds etc. Even the kind of compensation calculation algorythm that cubase has (with total path compensation constrainsts, ability to switch compensation for specific paths for recording etc is not actually hard to calculate and implement. You model the audio, midi and control flow network, identify the syncronisation points (ie where one path has to be in sync with another - for eg at a mix/send bus, or sidechain input, master out etc) and pad out the shorter path segments with micro-delay times to they are all as long as the longest parallel path. A vaguely interesting algortythm but not a hard one nor is it hard to create good test cases for it and test it.
Now long techy bit that most will probaby have no desire to read at all, but might help folks who are interested to understand the problem space.
Calls from plugins to read VST time (a whole load of suff is read by this - including sample position as well as music time etc) can be compensated according to the known offset for that plugin and that will deal with clock sync. The host can also adjust the time basis for its automation lanes.
What is generally alot harder to do is deal with automations that are not generated by the host and instead are generated by a plugin which are themselves delayed - for example automation done via Max4Live, however there are a couple of obvsious generic way to deal with that come to mind. Oe of them samples automation data and treats it like mono audio (very good way to delay automaion changing at full audio rate), the other buffers and delay change information (not so good when an automation changes at full audio rate) and one could conceive and combination of the two to efficient and generically manage both host generated and plugin generated automation.
Max for Live is a spanner in the works for all of this. If you compensate automation into max for live, and yet the run time is using an uncompensated clock, then outgoing automations could be skewed where the autogoing results from some calculation based upon an incoming automation and the clock, so any kind of automation comensation will have considerable implications for the Max4Live run time, but taking a step back, just need Max4Live's clock to be like any other plugin clock and problem solved there, however this will then break the timing of direct parameter control for M4L - unless all parameter have a means to buffer and delay their automation data - which comes back to the generic approach for managing automation to solve this.
For anything that needs an input (audio, midi, automation, clock) you need to know huge much that input needs to be delay by at that point in the path and provide a accurate and effficient mechanism to do it. Then it become upto the network evaluation to fill in the numbers accordinding to what is going on elsewhere. BTW - the longest path will generally be the value to need to be applied to the visible play head indicator to make sure its over what you actually hear, rather than some way in front.
The kind of interesting bits of code I quite like doing
All of this decription is to help folks undersand the problem space if they care to / feel the need. It certainly isnt trivial, but nor is it really hard either with one relaly big caveat - if its designed to deal with all of this in the first place. If it isn, then its an example of something that should be re-written rather than fixed. It mayb not even be implemented in live in a self contained manner - may be spreadm throught out much of the code base - meaning that any tweaks are going to be really hard to implement and test.
Only Abletons developers know these things, in particular Ive mention VST plugins as I know how they work - Live's plugins may simply not work the same way. When a Live native plugin need to know compensated time, actually the API may have no way of knowing which plugin is requesting this and so cant actually compensate the time for it. I am guessing that VST (and AU) is effectively a bridge from lives native plugin system to VST (and AU), then again - no way to ever make it work properly without a significant change to not only the the core of live, but also every plugin.
I wouldnt mind betting that the core native plugin architecture of live was strongly influenced by VST 1.0 with a bunch of enhancements to suit the immediate design goals fo Live rather than VST 2.3/4 etc. If thats the case - you aint going to see this fixed for a very long time.
So, it gets thrown into the same bucket as 64 bit, VST3, bezier curve automations and various other things that have been hinted as being impossible within the current architecture. Nearly every long term software project eventually hits a brick wall where some serious rethinking has to be done in order to move on. Its not uncommon for the signs of getting close to that brick wall are where it gets really buggy and bloated and hard to manage the code etc.
A change in this kind of thing possibly has to impact everything in core Live, Max 4 live and all live native plugins (at a guess - Ive never seen the code for live obviously, I'm just someone who has a reasonable idea how this stuff works under the hood and done alot of this kind of thing in the past for digital video editing, control and fx systems).
In Cubase 6 where is all works pefectly, alot of folks are probbaly doing guitar band/accoutic etc where TBH it rarely matters because you are dealing with h=normnal human timing rather than precise machine timing anyway
I really dont want to have to use Cubase 6 for this kind of thing - while this version can cope with routing etc, it such a pain to set them up and edit vs the rapid simplicity of doing it in Live with its drag and drop etc that I just dont want to have to endure the likes of cubase more than nescessary.
These days stuff like this should just work without hacks, work arounds etc. Even the kind of compensation calculation algorythm that cubase has (with total path compensation constrainsts, ability to switch compensation for specific paths for recording etc is not actually hard to calculate and implement. You model the audio, midi and control flow network, identify the syncronisation points (ie where one path has to be in sync with another - for eg at a mix/send bus, or sidechain input, master out etc) and pad out the shorter path segments with micro-delay times to they are all as long as the longest parallel path. A vaguely interesting algortythm but not a hard one nor is it hard to create good test cases for it and test it.
Now long techy bit that most will probaby have no desire to read at all, but might help folks who are interested to understand the problem space.
Calls from plugins to read VST time (a whole load of suff is read by this - including sample position as well as music time etc) can be compensated according to the known offset for that plugin and that will deal with clock sync. The host can also adjust the time basis for its automation lanes.
What is generally alot harder to do is deal with automations that are not generated by the host and instead are generated by a plugin which are themselves delayed - for example automation done via Max4Live, however there are a couple of obvsious generic way to deal with that come to mind. Oe of them samples automation data and treats it like mono audio (very good way to delay automaion changing at full audio rate), the other buffers and delay change information (not so good when an automation changes at full audio rate) and one could conceive and combination of the two to efficient and generically manage both host generated and plugin generated automation.
Max for Live is a spanner in the works for all of this. If you compensate automation into max for live, and yet the run time is using an uncompensated clock, then outgoing automations could be skewed where the autogoing results from some calculation based upon an incoming automation and the clock, so any kind of automation comensation will have considerable implications for the Max4Live run time, but taking a step back, just need Max4Live's clock to be like any other plugin clock and problem solved there, however this will then break the timing of direct parameter control for M4L - unless all parameter have a means to buffer and delay their automation data - which comes back to the generic approach for managing automation to solve this.
For anything that needs an input (audio, midi, automation, clock) you need to know huge much that input needs to be delay by at that point in the path and provide a accurate and effficient mechanism to do it. Then it become upto the network evaluation to fill in the numbers accordinding to what is going on elsewhere. BTW - the longest path will generally be the value to need to be applied to the visible play head indicator to make sure its over what you actually hear, rather than some way in front.
The kind of interesting bits of code I quite like doing
All of this decription is to help folks undersand the problem space if they care to / feel the need. It certainly isnt trivial, but nor is it really hard either with one relaly big caveat - if its designed to deal with all of this in the first place. If it isn, then its an example of something that should be re-written rather than fixed. It mayb not even be implemented in live in a self contained manner - may be spreadm throught out much of the code base - meaning that any tweaks are going to be really hard to implement and test.
Only Abletons developers know these things, in particular Ive mention VST plugins as I know how they work - Live's plugins may simply not work the same way. When a Live native plugin need to know compensated time, actually the API may have no way of knowing which plugin is requesting this and so cant actually compensate the time for it. I am guessing that VST (and AU) is effectively a bridge from lives native plugin system to VST (and AU), then again - no way to ever make it work properly without a significant change to not only the the core of live, but also every plugin.
I wouldnt mind betting that the core native plugin architecture of live was strongly influenced by VST 1.0 with a bunch of enhancements to suit the immediate design goals fo Live rather than VST 2.3/4 etc. If thats the case - you aint going to see this fixed for a very long time.
So, it gets thrown into the same bucket as 64 bit, VST3, bezier curve automations and various other things that have been hinted as being impossible within the current architecture. Nearly every long term software project eventually hits a brick wall where some serious rethinking has to be done in order to move on. Its not uncommon for the signs of getting close to that brick wall are where it gets really buggy and bloated and hard to manage the code etc.
A change in this kind of thing possibly has to impact everything in core Live, Max 4 live and all live native plugins (at a guess - Ive never seen the code for live obviously, I'm just someone who has a reasonable idea how this stuff works under the hood and done alot of this kind of thing in the past for digital video editing, control and fx systems).
Last edited by Khazul on Fri Jan 21, 2011 2:39 pm, edited 3 times in total.
Nothing to see here - move along!
Re: Live + 3rd party plugins = FAIL
It explains where many of the perceptions of Live sound quality might arise from, and in that its actually a very good post on a touchy subject. There is one bit Im not entirely convinced of, but it might just be an offhand remark to simplify the real situation (about grains in summing etc).LoopStationZebra wrote:Again, not sure how many of you read this guy's post over at IDM, but it really does explain it all quite nicely.
As for summing/gain algorythms - there are two I have commonly used - which depends on whether you are working in a high precision floating point system, or a suitabley high precision fixed point system, either way - given sufficient precision - noone is going to tell the difference from rendered audio nor will there be difference between the floating point result multiplied by suitable integer and rounded compared to the interger result of the integer calculation, but thats getting OT...
Nothing to see here - move along!
Re: Live + 3rd party plugins = FAIL
anyone remember this thread?
Sep 10, 2008 - "'Automatic latency compensation' TRULY sucks!"
http://forum.ableton.com/viewtopic.php? ... &hilit=pdc
Sep 10, 2008 - "'Automatic latency compensation' TRULY sucks!"
http://forum.ableton.com/viewtopic.php? ... &hilit=pdc
In my life
Why do I smile
At people who I'd much rather kick in the eye?
-Moz
Why do I smile
At people who I'd much rather kick in the eye?
-Moz
-
LoopStationZebra
- Posts: 10586
- Joined: Sat Jan 17, 2009 5:57 pm
- Contact:
Re: Live + 3rd party plugins = FAIL
Has anyone from Ableton every acknowledged this issue?
Soundcloud: http://soundcloud.com/rimby
i7-3770K 3.5GHz
16GB RAM
256GB SSD, 1TB 7200HD
Windows 8
Live 9
i7-3770K 3.5GHz
16GB RAM
256GB SSD, 1TB 7200HD
Windows 8
Live 9
Re: Live + 3rd party plugins = FAIL
Forgotten about that one - and learn alot more about this wierdness since.Tone Deft wrote:anyone remember this thread?
Sep 10, 2008 - "'Automatic latency compensation' TRULY sucks!"
http://forum.ableton.com/viewtopic.php? ... &hilit=pdc
Nothing to see here - move along!
Re: Live + 3rd party plugins = FAIL
I remember someone back in the day talking a lot about PDC problems, they ranted about it. I don't rely on 3rd party effects so I never really paid attention.Khazul wrote:Forgotten about that one - and learn alot more about this wierdness since.Tone Deft wrote:anyone remember this thread?
Sep 10, 2008 - "'Automatic latency compensation' TRULY sucks!"
http://forum.ableton.com/viewtopic.php? ... &hilit=pdc
looks like PDC was introduced in Live 5, I think.
here's Andreas talking about PDC and sends, not exactly what's in this thread, but...
http://forum.ableton.com/viewtopic.php?p=171710#p171710
a search on hoffman2k and PDC shows some ins and outs of PDC.
http://forum.ableton.com/search.php?key ... mit=Search
(hope you don't mind hoff.)
In my life
Why do I smile
At people who I'd much rather kick in the eye?
-Moz
Why do I smile
At people who I'd much rather kick in the eye?
-Moz
Re: Live + 3rd party plugins = FAIL
Hi Folks,
just wanted to chime in and confirm a few things, so you don't have to waste too much studio time discussing technical speculations or checking test scenarios to find out what exactly happens in Live and what not - you're right in stating that it is our job to explain this!
In short: Live's Plugin Delay Compensation compensates the audio.
What it does not, is compensating automation or what the Live GUI is showing (moving meters etc.), just as we always stated.
Even more important for this thread: timing depending plugins like camelspace or beatrepeat poll the transport timing information from the host to work correctly in time. In Live's case, as well with some other hosts, all plugins get the same global timing and normally this is just fine, of course - but as soon as such a timing depending plugin sits behind another plugin that causes latency, it would need its own special timing information that incorporates also the latency that gets introduced before it receives its data. But as i mentioned: Live does not offer this feature yet, just as it does not offer automation compensation - and both are pretty huge points on the feature wishlist.
Therefore ninox_rufa is pretty spot on in the descriptions he posted in this thread and we also confirmed this to him via support emails months ago.
If it would have been a bug, i'm pretty sure we would have addressed it by now during the quality initiative.
But unfortunately it is not something that is broken but actually a wish for new features based on the basic PDC (a. compensating automations, b. compensating host timing information based on where the plugin sits, c. GUI compensation) which cannot be hacked together in a few hours or days.
Nevertheless, we already said we will address these feature wishes and this statement still holds true.
But as always with Ableton products - we can't make any promises or announcements regarding the timeframe for this. Sorry for this.
What also already has been said is that as long as those delay compensation features are missing, we have to work on the manual in order to explain the situation better as it is confusing to the customer right now. And this came personally from the man who takes care of the manual, so we can trust this statement (http://forum.ableton.com/viewtopic.php?f=1&t=129443).
I hope this clears up the confusion a bit. We really don't want to hide facts or information about such things and if there are further technical questions regarding this topic, feel free to contact support@ableton.com anytime for an answer, as it is hard to keep track of all the posts in the forum.
Cheers,
Dom
just wanted to chime in and confirm a few things, so you don't have to waste too much studio time discussing technical speculations or checking test scenarios to find out what exactly happens in Live and what not - you're right in stating that it is our job to explain this!
In short: Live's Plugin Delay Compensation compensates the audio.
What it does not, is compensating automation or what the Live GUI is showing (moving meters etc.), just as we always stated.
Even more important for this thread: timing depending plugins like camelspace or beatrepeat poll the transport timing information from the host to work correctly in time. In Live's case, as well with some other hosts, all plugins get the same global timing and normally this is just fine, of course - but as soon as such a timing depending plugin sits behind another plugin that causes latency, it would need its own special timing information that incorporates also the latency that gets introduced before it receives its data. But as i mentioned: Live does not offer this feature yet, just as it does not offer automation compensation - and both are pretty huge points on the feature wishlist.
Therefore ninox_rufa is pretty spot on in the descriptions he posted in this thread and we also confirmed this to him via support emails months ago.
If it would have been a bug, i'm pretty sure we would have addressed it by now during the quality initiative.
But unfortunately it is not something that is broken but actually a wish for new features based on the basic PDC (a. compensating automations, b. compensating host timing information based on where the plugin sits, c. GUI compensation) which cannot be hacked together in a few hours or days.
Nevertheless, we already said we will address these feature wishes and this statement still holds true.
But as always with Ableton products - we can't make any promises or announcements regarding the timeframe for this. Sorry for this.
What also already has been said is that as long as those delay compensation features are missing, we have to work on the manual in order to explain the situation better as it is confusing to the customer right now. And this came personally from the man who takes care of the manual, so we can trust this statement (http://forum.ableton.com/viewtopic.php?f=1&t=129443).
I hope this clears up the confusion a bit. We really don't want to hide facts or information about such things and if there are further technical questions regarding this topic, feel free to contact support@ableton.com anytime for an answer, as it is hard to keep track of all the posts in the forum.
Cheers,
Dom
ableton support team
support@ableton.com
support@ableton.com
-
LoopStationZebra
- Posts: 10586
- Joined: Sat Jan 17, 2009 5:57 pm
- Contact:
Re: Live + 3rd party plugins = FAIL
dom wrote:If it would have been a bug, i'm pretty sure we would have addressed it by now during the quality initiative.
But unfortunately it is not something that is broken but actually a wish for new features based on the basic PDC (a. compensating automations, b. compensating host timing information based on where the plugin sits, c. GUI compensation) which cannot be hacked together in a few hours or days.
Tnx dom.
Those claiming it was a bug may want to offer a mea culpa now.
I came for the
But stayed for the
But stayed for the
Re: Live + 3rd party plugins = FAIL
nah, not necessary... maybe just a bit less emotions and aggression when it comes to such topics...
we folks here at ableton also still use live just as you all do and if there are shortcomings, then you can be 99,9% sure that we know of them and that they bother us, too. maybe even more, as we're sitting on this side of the screen.
good weekend to you all!
dom
we folks here at ableton also still use live just as you all do and if there are shortcomings, then you can be 99,9% sure that we know of them and that they bother us, too. maybe even more, as we're sitting on this side of the screen.
good weekend to you all!
dom
ableton support team
support@ableton.com
support@ableton.com