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

Simplified submodule wrapper for one-off operations #30

Open
ejhumphrey opened this issue Nov 1, 2016 · 3 comments
Open

Simplified submodule wrapper for one-off operations #30

ejhumphrey opened this issue Nov 1, 2016 · 3 comments
Assignees
Labels

Comments

@ejhumphrey
Copy link
Contributor

ejhumphrey commented Nov 1, 2016

so here's a idea for discussion...

I like the transform chaining for complex effects; it's a really smart way of optimizing how sox is controlled. However, I don't like how verbose it is for simple one-off operations.

For example, to convert a file currently:

tfm = sox.Transformer()
tfm.convert(
    samplerate=samplerate, 
    n_channels=n_channels,
    bitdepth=bitdepth)
tfm.build(input_file, output_file)

For simple operations, this doesn't feel very pythonic. I'd be curious how folks feel about abstracting this away for trivial / common pipelines:

sox.effects.convert(input_file, output_file, samplerate, n_channels, bitdepth)

This could also roll-up try-catch logic, if one were so inclined (e.g. strict=False could return a non-zero status, etc).

thoughts?

@ejhumphrey
Copy link
Contributor Author

added benefit, any future changes to the Transformer base class / interface would be hidden, insulating users / code upstream... because change is inevitable.

@rabitt
Copy link
Collaborator

rabitt commented Nov 1, 2016

@ejhumphrey good idea. I've been thinking about creating a utils or cookbook module for a while now for this kind of thing. The challenge is in deciding which simple operations are common enough to get a standalone function. convert seems like a reasonable one, but what else? Maybe more "complex" things like crossfade that are clunky to do as is?

@ejhumphrey
Copy link
Contributor Author

i'd tackle them on an as-needed / requested basis, and let use case / need drive what gets implemented.

@rabitt rabitt added this to the 1.4 milestone Feb 13, 2017
@rabitt rabitt self-assigned this Feb 13, 2017
@rabitt rabitt removed this from the 1.4 milestone Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants