marl / pysox

Python wrapper around sox.
BSD 3-Clause "New" or "Revised" License
514 stars 79 forks source link

Simplified submodule wrapper for one-off operations #30

Open ejhumphrey opened 7 years ago

ejhumphrey commented 7 years ago

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 commented 7 years ago

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

rabitt commented 7 years ago

@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 commented 7 years ago

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