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).
