If you'd like to see this implemented, please take a moment to up-vote the feature suggestion over on Centercode, using the following search code: L12-SUG-4509
TL;DR
I'd like to request a formal method for audio clip/event-level processes more optimal than simple device automation and with built-in reversion potential to allow for future modification(s) that audio bouncing can't provide.
Note: Of the various forms of this type of functionality across DAWs, Pro Tools' implementation is arguably the least desirable and was merely included in the title for the sake of its familiarity being decidedly the most ubiquitous.
Feature Request:
A feature that would greatly enhance my workflow is an offline, audio clip-based processing mode à la Pro Tools' "Audio Suite", Cubase's "Direct Offline Processing", Reaper's "Item FX", and Studio One's "Event FX". These features, though philosophically similar, are all technically diverse. Obviously, Ableton's implementation, which I've naturally dubbed 'Clip FX', would (and should) differ with respect to Live-specific programming framework(s); I've only named these rival applications for the sake of reference.
Feature Definition:
With Clip FX, one would essentially be able to apply stock and M4L devices as well as third-party plugins to individual audio clips as opposed to whole tracks, which lends itself to greater creative possibilities but also helps with more technical processes like audio editing (e.g., applying an RX module to clean up a brief audio segment). Although many of us are likely familiar with this functionality, I wanted to account for potential voters who may be unaware.
Current Workarounds:
We can achieve similar functionality simply by automating inserts to activate or deactivate as needed or by separating and bouncing specific clips with whatever FX we need. But, these approaches are sub-optimal for two main reasons (one admittedly personal): (1) First, certain plugins, especially certain RX modules, introduce substantial latency, which justifies the need for an offline processing mode that bypasses said latency-introduction by affecting the audio clip(s) on a source-level; and (2) Secondly, due to the destructive nature of this process, there needs to be a built-in method for reversion to allow for future modification. Automation doesn't address the latency problem, and bouncing makes it so that these changes can't be undone. We can save a copy of the project with the non-bounced track(s) in order to return and make changes as necessary while bouncing in the main project, thereby keeping the main project as latency-free as possible. However, now, we're micro-managing multiple sessions, which is - again - less than optimal.