On Fri, Feb 13, 2009 at 9:48 AM, Pascal Giard <evilynux@gmail.com> wrote:
On Thu, Feb 12, 2009 at 5:09 PM, robs <aquegg@yahoo.co.uk> wrote:
> --- On Sun, 8/2/09, robs <aquegg@yahoo.co.uk> wrote:
>> > I wonder if an environment variable, such as
>> > "SOX_FLAGS" that works like the LESS
>> variable
>> > does for less, would be appropriate.
>> When I raised the soxrc FR I think I thought that env.
>> vars. should really only be used for things that might be
>> used by more than one app.
>> Nevertheless, I've hacked something in for a var called
> What do people think about this. Should this be released as a feature?
> If so, perhaps there should also be a PLAY_OPTS, REC_OPTS, maybe absorbing the exist PLAY_RATE_ARG var.  Or is this all going in the direction...?

Perhaps both could be implemented but i'd rather see some sort of
sox.conf support.
There could be a rec and play section (or whatever required) in there.
There could be an argument allowing the user to specify a different
configuration file.

Would that make sense?

When applications support these concepts, I appreciate it when they support both ways.  There are times when env vars are more convenient and there are times when files are more convenient.  I don't think there is one true way here.

If we implement a SOX_OPTS, I think we should keep a separate PLAY_OPTS/REC_OPTS or stick with current PLAY_RATE.  Rob, I think you can comment best on if existing feature should be changed to more generic PLAY_OPTS vs. PLAY_RATE_ARG since you got that part working in the first place.

Let me start the next part by saying that the only use case I really understand is a user wanting a way to specify command line options using SOX_OPTS, a random text file, or .soxrc if it exists.  In other words, regardless if you use SOX_OPTS or a text file, the behavior is no different then as if user specified on command line; with exception  of rules when its specified multiple ways.

In that case, I can see need to keep PLAY_RATE_ARG separate from SOX_OPTS.  User may wish to do both together:

*) Set and forget in a login file any hardware specific values using PLAY_RATE_ARG.
*) Set session specific values that will be repeatedly used for current work flow using SOX_OPTS/.soxrc/text file.

In the FR,  I think it was mentioned that user may want a .soxrc to be used in ways different then a simple command line replacement (define aliases for different work flows).  If thats the case, it might be better to create --command-file option to specify a filename user wants to use just for command line replacement and leave .soxrc for another day.