You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a bit unintuitive to me why the I/O of process_fn must be a path. Is this somehow a consequence of ARA processing?
I recognize that it is very convenient for the input to be a path, since one can then define predictable pre-processing steps for audio, but I'm curious if it must be this way? What if the input audio was instead recorded and thus stored in RAM?
In terms of the output, given the nature of gradio applications (and audio plugins), where there is no (at least user-facing) output path for the processed audio, it seems a bit clunky that one should have to define a process for saving the processed audio.
At the very least I think the README should provide more context for why this current protocol is adopted.
The text was updated successfully, but these errors were encountered:
It is a bit unintuitive to me why the I/O of
process_fn
must be a path. Is this somehow a consequence of ARA processing?I recognize that it is very convenient for the input to be a path, since one can then define predictable pre-processing steps for audio, but I'm curious if it must be this way? What if the input audio was instead recorded and thus stored in RAM?
In terms of the output, given the nature of gradio applications (and audio plugins), where there is no (at least user-facing) output path for the processed audio, it seems a bit clunky that one should have to define a process for saving the processed audio.
At the very least I think the README should provide more context for why this current protocol is adopted.
The text was updated successfully, but these errors were encountered: