Re: AU "offline" processing
Re: AU "offline" processing
- Subject: Re: AU "offline" processing
- From: James Chandler Jr <email@hidden>
- Date: Mon, 03 Feb 2003 14:16:36 -0500
One more "dumb" idea and I'll shut up (GRIN).
Another "easy" option for roll-your-own offline processors (for things like
reverse, fade-in-out, normalize, stretch, trim, other stuff "inconvenient
and messy" with ordinary 1-to-1 processor plugins)...
Awhile ago on a PC implementation, we wrote our offline "plugins" by just
designing the "plugins" as small specialized standalone helper applications.
The host would write an "input.txt" file for the plugin to read, with info
about the files to process, regions to process, etc. Then the host would
launch the helper app and wait for the helper app to terminate.
The helper app would read "input.txt", put up a user settings window,
process the files/regions if the user hit "OK", write an "output.txt" file
with result codes, and quit.
After the helper app quits, the host reads "output.txt" to see if processing
was successful, and determine if it needs to do anything to adjust for
changed data.
Compared to "real plugins" it is a little extra trouble writing the first
helper app because it has to implement parsing, file-access, and audio
preview. But for subsequent plugs, the core support code remains largely
unchanged. The only "custom" stuff you have to write for each new plug is
the user interface and the actual DSP routines.
Admittedly this is kludgy, but it is simple, it works, and doesn't take long
to write (at least compared to something more "elegant and ambitious").
The Premiere plugins had some similarity to this approach, except the host
would load the plugin, and handle random-access audio file access requests
from the plugin via callbacks to the host.
The Premiere host would load the plugin and tell it to put up its user
dialog, then surrender control to the plugin.
If the user clicked OK in the plugin, the host would then call a "process"
function in the plugin, and again surrender control until the plugin was
done processing the audio. When the plugin needed to read or write audio,
the host callbacks would perform these functions for the plugin.
James Chandler Jr.
>
Marc, with random access to the source audio, there's no reason such
>
plug-ins cannot be run in real time.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.