Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Context for why I/O must be a path to audio. #5

Open
cwitkowitz opened this issue Nov 1, 2023 · 0 comments
Open

Context for why I/O must be a path to audio. #5

cwitkowitz opened this issue Nov 1, 2023 · 0 comments
Assignees

Comments

@cwitkowitz
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants