ARA - Audio-Random-Access - a new offline processing plugin standard - will this take off?

[AdmiralQuality]

If you need to know what a sample n samples ahead is, wait for it. If you need to know what a sample n samples ago was, remember it.

That's a terrible "solution" that requires the user to wait in real time for the plugin to "record" the audio. Also if the user edits anything in the host after such recording is complete, the audio has to be recorded into the plugin again. This is severely annoying, inefficient and time wasting.

No, sorry. It's actually an offline plug-in that needs the audio recorded beforehand. Obviously if I need the value of a sample a minute from now, that's not going to work live.

This all is about audio that has been previously recorded/imported into the host, not about realtime live playing/input, so don't use that as a red herring...If you have no use for processing like that, fine, but don't discourage other people from exploring such options.

Then don't tell me you have to 'wait in real time for the plugin to "record" the audio' when you're talking about pre-recorded material.

[Xenakios]

Then don't tell me you have to 'wait in real time for the plugin to "record" the audio' when you're talking about pre-recorded material.

That is exactly how something like Melodyne works as plugin without ARA support : the user has to record the audio into the plugin from the host, in real time. And that recording process has to happen again each time the audio on the host tracks has been altered in some way. You could watch some videos on the Celemony website that make this process clear. (And also the videos about ARA which should explain why ARA is useful in order to avoid that time consuming and inconvenient audio transfer step.) Besides Melodyne, there are not many other plugins currently in the market that work like this, but Schwa's Dyno and Spectro come to mind. (And they work equally badly to non-ARA enabled Melodyne...)

[AdmiralQuality]

Sure. But you don't need to pump the audio through it in real time in "learn/scan" mode. You could just render the track and it goes as fast as possible. But yes, you'd need another pass to do the output as a real-time plug-in can't impose arbitrarily long delay.

Why even have them be plug-ins at that point though? Why not just a separate app that processes a sound file?

[arakula]

Why even have them be plug-ins at that point though? Why not just a separate app that processes a sound file?

Consistent workflow.

[AdmiralQuality]

Wouldn't it be neat if you could drag an .exe onto an audio track instead of the other way around?

[Xenakios]

Wouldn't it be neat if you could drag an .exe onto an audio track instead of the other way around?

Haha, this might actually be pretty interesting...

[Music Engineer]

Why even have them be plug-ins at that point though? Why not just a separate app that processes a sound file?

yes, that's pretty much what we have to do these days without such an offline plugin interface. but it would be more convenient to be able to do such stuff with plugins as well. you mentioned yourself two examples of very simple processes that need such random access (time reversal and normalization). bi-directional filters were already mentioned by antto. but with a bit of imagination, one can come up with tons of more stuff. melodyne itself provides timestretching which is another obvious candidate. (@antto:) in this case, the lengths of the input and output buffers would differ, which makes the vst interface inappropriate, even when assuming the whole data to be passed in a single big buffer.

[efluon]

Processing buffer by buffer can be severely limiting, especially for processes that need an expensive analysis stage, like pitchcorrection, noisereduction, etc. With several pitchmodification-plugs there is difference in quality between a pure realtime mode and a mode with previous "recording". A benefit of having this as a plugin is the realtime usabilzy in context (i.e. with tempoinfo and other tracks).