A comment on the sample rc file: sometimes you say "similar to" a given command line option. The rc options should be *identical to* command line options, and the parsers automatically generated from the same source. I suggest that lines should look like this:
[EFFECT|FORMAT =]OPTION...
which means: for the given effect or format, use the relevant options (or if none is specified, always use them).
You could add some pseudo-effect or format options. For example, for my use, I'd like to specify a large input buffer, but only when reading from the internet, so a "url" pseudo-format could be used:
url = input-buffer=1000000
I suggest you look into using libpopt, as it already provides support for configuration files using command-line arguments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A note about a related feature. SoX 14.2.0 will have a new --effects-file option. It reads a file and uses its contents just like user specified it on the command line. Adding a --files-file that works in the vein but for filenames and related options wouldn't be to hard to add. The main problem with current code though is that they are used in place of and not a complement of command line options.
Reviewing the sample config file and requests for url/format specific default, I think the real requests seems to be limited to auto-setting --options and not so much short hands for filenames or effect names. Since we have the --effects-file now, who ever adds this can concentrate on just fixed and conditional option setting.
I looked at libpopt a little bit and seems like it would be about the same amount of work to write custom alias support in a custom config file then it would to reorganize our internals to support it. The custom version would be much more flexible as well. libpopt is a nice concept though over all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can we please close this, after more than a decade?
As to the feature itself: the proposed .soxrc introduces new syntax,
which would require a new parser, as if that's not a mess already.
If sox ever has this, let's agree the syntax has to be identical to the command line;
at which point the only feature is that you don;t have to type it;
which imho means it's not even worth the extra complexity.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we can unite all these requirements. It's /etc/soxrc, $HOME/.soxrc
because I'm old and I get to decide :) I'm sure .local/ and .config/ are nice
but dot files and rcs are old-skool and SoX is old-skool. And I'm old-skool.
sox.sf.net has never used /etc/soxrc so we can swipe it
instead of cowering under a sox_ngrc or a soxrc_ng.
I assume that "identical to the command line" means
"with the leading -- for lines like --combine mix" when saying
"when I give multiple files, I want to hear them all simultaneously
because I'm mixing something down."
This also suggests adding options to set different default combine types
for sox and for play. Does rec take input files?
Making config lines
--buffer-size-url 8k
also lets us add effect lines at the end so that automatic rate resampling
is applied to everything or whatever.
If the config file is read before the command-line options
so that command-line options override the config file, this will
place the config file's effects before the command-line's ones
We have to separate out the effect lines from the - lines anyway
because concatting them would put cmdline global options after
effects so we could place effect lines before any - lines at the
start of the effect chain and add any after the - lines at the end.
What if the go effects, options, effects, options, effects?
I suppose that could work if global options could be invoked
in the middle of parsing for effect names
Template soxrc for /etc & $HOME
Logged In: YES
user_id=27473
Originator: YES
See attached file.
Logged In: YES
user_id=36773
Originator: NO
I'm not arguing the feature itself but wondering why not use a sox.conf filename instead of the less frequently used *rc filename?
I want this too: I want to be able to specify a large input buffer when playing URLs.
As far as the name goes, ".conf" is more logical, even if "rc" has historical currency. But it's not very important.
A comment on the sample rc file: sometimes you say "similar to" a given command line option. The rc options should be *identical to* command line options, and the parsers automatically generated from the same source. I suggest that lines should look like this:
[EFFECT|FORMAT =]OPTION...
which means: for the given effect or format, use the relevant options (or if none is specified, always use them).
You could add some pseudo-effect or format options. For example, for my use, I'd like to specify a large input buffer, but only when reading from the internet, so a "url" pseudo-format could be used:
url = input-buffer=1000000
I suggest you look into using libpopt, as it already provides support for configuration files using command-line arguments.
A note about a related feature. SoX 14.2.0 will have a new --effects-file option. It reads a file and uses its contents just like user specified it on the command line. Adding a --files-file that works in the vein but for filenames and related options wouldn't be to hard to add. The main problem with current code though is that they are used in place of and not a complement of command line options.
Reviewing the sample config file and requests for url/format specific default, I think the real requests seems to be limited to auto-setting --options and not so much short hands for filenames or effect names. Since we have the --effects-file now, who ever adds this can concentrate on just fixed and conditional option setting.
I looked at libpopt a little bit and seems like it would be about the same amount of work to write custom alias support in a custom config file then it would to reorganize our internals to support it. The custom version would be much more flexible as well. libpopt is a nice concept though over all.
Note that we now have SOX_OPTS (which doesn't necessarily supersede soxrc/sox.conf but may reduce its priority).
Has this ever been implemetned?
The manpage doesn't mention a ~/.soxrc file
No, it's not been implemented; still looks that, to some extent, it's useful to do so.
Can we please close this, after more than a decade?
As to the feature itself: the proposed .soxrc introduces new syntax,
which would require a new parser, as if that's not a mess already.
If sox ever has this, let's agree the syntax has to be identical to the command line;
at which point the only feature is that you don;t have to type it;
which imho means it's not even worth the extra complexity.
I think we can unite all these requirements. It's /etc/soxrc, $HOME/.soxrc
because I'm old and I get to decide :) I'm sure .local/ and .config/ are nice
but dot files and rcs are old-skool and SoX is old-skool. And I'm old-skool.
sox.sf.net has never used /etc/soxrc so we can swipe it
instead of cowering under a sox_ngrc or a soxrc_ng.
I assume that "identical to the command line" means
"with the leading -- for lines like --combine mix" when saying
"when I give multiple files, I want to hear them all simultaneously
because I'm mixing something down."
This also suggests adding options to set different default combine types
for sox and for play. Does rec take input files?
Making config lines
--buffer-size-url 8k
also lets us add effect lines at the end so that automatic rate resampling
is applied to everything or whatever.
If the config file is read before the command-line options
so that command-line options override the config file, this will
place the config file's effects before the command-line's ones
We have to separate out the effect lines from the - lines anyway
because concatting them would put cmdline global options after
effects so we could place effect lines before any - lines at the
start of the effect chain and add any after the - lines at the end.
What if the go effects, options, effects, options, effects?
I suppose that could work if global options could be invoked
in the middle of parsing for effect names
See https://codeberg.org/sox_ng/sox_ng/issues/740#user-content-conclusion