The latest CVS version of Csound5 sets the default for -+rtaudio
from the environment variable CSRTAUDIO; if it is unset or empty,
the default is PortAudio (as it was before the change).
Of course, the -+rtaudio command line option, if specified, will
override whatever is set in CSRTAUDIO.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Istvan,

I have tried using -+rtaudio=alsa in a .csoundrc file but it has not 
worked for me.  It seems that rather than use yet another environment 
variable, it would be better to have .csoundrc be usable in this case.  
What do you think?

steven

Istvan Varga wrote:

> The latest CVS version of Csound5 sets the default for -+rtaudio
> from the environment variable CSRTAUDIO; if it is unset or empty,
> the default is PortAudio (as it was before the change).
> Of course, the -+rtaudio command line option, if specified, will
> override whatever is set in CSRTAUDIO.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

steven yi wrote:

> I have tried using -+rtaudio=alsa in a .csoundrc file but it has not 
> worked for me.  It seems that rather than use yet another environment 
> variable, it would be better to have .csoundrc be usable in this case.  
> What do you think?

Not a bad idea, although I have not used .csoundrc yet, so I do not know
what bugs it has. It might be worth having a look at, though.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Actually, .csoundrc seems to work, the only problem is that it is always
searched in the current directory, and not in $HOME. However, I have already
committed CVS changes that fix this. Now, .csoundrc is searched in the
following order:
   1. file defined in CSOUNDRC with full path (e.g. C:\CSOUND\CSOUND.CFG)
   2. .csoundrc in the HOME directory, if HOME is set and is not empty
   3. .csoundrc in the current directory


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

There were problems in Csound 4 with the interaction between readOptions()
and argdecode().  These showed up mostly when using .csoundrc, -@, or
 with long options (--).  I have mostly fixed the bugs in Csound
4 but not Csound 5.

Is it possible that the -+rtaudio code suffers from the same issues?

Maybe I should add the fixes from Cs4 sometime soon ....

Anthony


On 2/17/05 11:35 AM, Istvan Varga  etched in stone:

> steven yi wrote:
> 
>> I have tried using -+rtaudio=alsa in a .csoundrc file but it has not
>> worked for me.  It seems that rather than use yet another environment
>> variable, it would be better to have .csoundrc be usable in this case.
>> What do you think?
> 
> Not a bad idea, although I have not used .csoundrc yet, so I do not know
> what bugs it has. It might be worth having a look at, though.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Beautiful!  I have always wanted to use .csoundrc and had always placed 
it in $HOME thinking it was just broken code somewhere in the parsing. 
I'm glad it was a matter of where it was looking.  Looking forward to 
trying this out at home on linux and will try on Windows shortly.

Thanks!
steven


Istvan Varga wrote:
> Actually, .csoundrc seems to work, the only problem is that it is always
> searched in the current directory, and not in $HOME. However, I have 
> already
> committed CVS changes that fix this. Now, .csoundrc is searched in the
> following order:
>   1. file defined in CSOUNDRC with full path (e.g. C:\CSOUND\CSOUND.CFG)
>   2. .csoundrc in the HOME directory, if HOME is set and is not empty
>   3. .csoundrc in the current directory
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> There were problems in Csound 4 with the interaction between readOptions()
> and argdecode().  These showed up mostly when using .csoundrc, -@, or
>  with long options (--).  I have mostly fixed the bugs in Csound
> 4 but not Csound 5.

Here is the diff between Csound4 and Csound5 readOptions():

-int readOptions(void *csound, FILE *unf)
+int readOptions(FILE *unf)
  {
      char *p;
@@ -222,11 +216,10 @@
  #endif
        /*      argc++; */                  /* according to Nicola but wrong */
-      /* Read an argv thing */
-      argdecode(csound, argc, argv, &filnamp, getenv("SFOUTYP"));
+      argdecode(argc, argv, &filnamp, getenv("SFOUTYP")); /* Read an argv thing */
      }
      return FALSE;
  }

The two versions seem to be identical other than the presence of a
csound pointer in Cs5. Also, one_file.c is generally the same in
Cs4 and Cs5, save for the usual differences related to reentrance,
use of csound instance pointers, and Str(); I did find changes in
the parsing of , but that is not relevant here.

Or, are the bugs you mentioned in argdecode.c and not in one_file.c
(that would affect parsing the command line too, not only .csoundrc) ?

> Is it possible that the -+rtaudio code suffers from the same issues?

What do you mean when referring to "-+rtaudio code" ?



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> There were problems in Csound 4 with the interaction between readOptions()
> and argdecode().  These showed up mostly when using .csoundrc, -@, or
>  with long options (--).  I have mostly fixed the bugs in Csound
> 4 but not Csound 5.

Now I found these filnamp hacks in argdecode.c. I assume the "interaction
problems" were caused by saving pointers to string arguments that were
going to be freed after parsing the options in the case of options specified
in files (CSD or .csoundrc), and the solution was to make a copy of the
strings. -+rtaudio is surely not affected by this as it is implemented using
new parser code that is more advanced than what is in argdecode.c, and does
make a copy of string arguments.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm glad that you changed this.  I was previously confused when Csound would
not find ~/.csoundrc on Unix.  And I recently changed this code on my local
copy of Cs4.

I am wondering though if there shouldn't be a more uniform way to search for
files.  It seems that every special file or type of file has its own search
path, environment variable(s), and thus its own code for doing the search.
And of course, each instance of this code has to be #ifdefed for non-POSIX
systems in order to have the most logical behavior for that platform.

Can we factor this type of code out into a single "filesearch" function with
options and default behaviors for each platform?
 
Anthony

On 2/17/05 12:43 PM, Istvan Varga  etched in stone:

> Actually, .csoundrc seems to work, the only problem is that it is always
> searched in the current directory, and not in $HOME. However, I have already
> committed CVS changes that fix this. Now, .csoundrc is searched in the
> following order:
> 1. file defined in CSOUNDRC with full path (e.g. C:\CSOUND\CSOUND.CFG)
> 2. .csoundrc in the HOME directory, if HOME is set and is not empty
> 3. .csoundrc in the current directory



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 2/17/05 1:54 PM, Istvan Varga  etched in stone:

> Or, are the bugs you mentioned in argdecode.c and not in one_file.c
> (that would affect parsing the command line too, not only .csoundrc) ?

Yes, I only changed code in argdecode.c.  But one of the problems was the
reuse of the buffer passed from readOptions to argdecode.  Come to think of
it, maybe I did not fix that yet ....

Anthony



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

There is a function already, fopenin, in Engine/filopen.c.  I think this 
does what you are talking about.  It should probably be exposed as 
csoundOpenFile or something along this lines as part of the API.

* fopenin() - patches fopen calls, searching file in current dir, INCDIR,
    SSDIR or SFDIR, in that order. Modelled on openin() above. (re May 
2000) */

FILE *fopenin(char *filnam)


steven


Anthony Kozar wrote:
> I'm glad that you changed this.  I was previously confused when Csound would
> not find ~/.csoundrc on Unix.  And I recently changed this code on my local
> copy of Cs4.
> 
> I am wondering though if there shouldn't be a more uniform way to search for
> files.  It seems that every special file or type of file has its own search
> path, environment variable(s), and thus its own code for doing the search.
> And of course, each instance of this code has to be #ifdefed for non-POSIX
> systems in order to have the most logical behavior for that platform.
> 
> Can we factor this type of code out into a single "filesearch" function with
> options and default behaviors for each platform?
>  
> Anthony
> 
> On 2/17/05 12:43 PM, Istvan Varga  etched in stone:
> 
> 
>>Actually, .csoundrc seems to work, the only problem is that it is always
>>searched in the current directory, and not in $HOME. However, I have already
>>committed CVS changes that fix this. Now, .csoundrc is searched in the
>>following order:
>>1. file defined in CSOUNDRC with full path (e.g. C:\CSOUND\CSOUND.CFG)
>>2. .csoundrc in the HOME directory, if HOME is set and is not empty
>>3. .csoundrc in the current directory
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> Yes, I only changed code in argdecode.c.  But one of the problems was the
> reuse of the buffer passed from readOptions to argdecode.  Come to think of
> it, maybe I did not fix that yet ....

I have made changes (it is already in the CVS) to argdecode to make a copy
of the argument list, and use pointers to this saved list. The use of filnamp
in argdecode is no longer needed, and string arguments should be saved
correctly.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It was deliberate that .csoundrc was looked for in the current
directory, so it could relate to the particular piece.   That is how I
work (when I get time).
==John ffitch


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> It was deliberate that .csoundrc was looked for in the current
> directory, so it could relate to the particular piece.   That is how I
> work (when I get time).

So, should it be searched in the current directory first, and then
try the other locations ?



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

.csoundrc is now read this way:

   1. a global file of which the location is either defined in the
      CSOUNDRC environment variable, or is $HOME/.csoundrc is
      read first, setting default options
   2. if there is a .csoundrc in the current directory, it will be
      read too, overriding any options previously set in the
      global rc file
   3. command line options are parsed, overriding .csoundrc settings

One problem remains: CSD options are read last, but actually the
command line should override the CSD, and not the other way, as it
currently is. This would require a second pass of parsing command
line options after the CSD has been read, but not sure if it is safe
to do.

Here is the code that reads .csoundrc:

     {
       char *csrcname;
       FILE *csrc;
       /* IV - Feb 17 2005 */
       csrcname = getenv("CSOUNDRC");
       csrc = NULL;
       if (csrcname != NULL && csrcname[0] != '\0') {
         csrc = fopen(csrcname, "r");
         if (csrc == NULL)
           err_printf(Str("WARNING: cannot open csoundrc file %s\n"), csrcname);
       }
       if (csrc == NULL &&
           (getenv("HOME") != NULL && ((char*) getenv("HOME"))[0] != '\0')) {
         /* 11 bytes for DIRSEP, ".csoundrc" (9 chars), and null character */
         csrcname = (char*) malloc((size_t) ((int) strlen(getenv("HOME")) + 11));
         if (csrcname == NULL) {
           err_printf(Str(" *** memory allocation failure\n"));
           longjmp(((ENVIRON*) csound)->exitjmp_,1);
         }
         sprintf(csrcname, "%s%c%s", getenv("HOME"), DIRSEP, ".csoundrc");
         csrc = fopen(csrcname, "r");
         free(csrcname);
       }
       /* read global .csoundrc file (if exists) */
       if (csrc != NULL) {
         readOptions(csound, csrc);
         fclose(csrc);
       }
       /* check for .csoundrc in current directory */
       csrc = fopen(".csoundrc", "r");
       if (csrc != NULL) {
         readOptions(csound, csrc);
         fclose(csrc);
       }
     }

















Istvan Varga wrote:
> jpff@codemist.co.uk wrote:
> 
>> It was deliberate that .csoundrc was looked for in the current
>> directory, so it could relate to the particular piece.   That is how I
>> work (when I get time).
> 
> 
> So, should it be searched in the current directory first, and then
> try the other locations ?
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have been thinking about this problem recently and it is more complicated
than it looks.  Not only do the command-line options get overridden by those
in the CSD but some options do not work "correctly" when specified in
multiple places.

For example, if there is -A in .csoundrc and -W in the CSD, then you get an
error saying that the output format cannot be both AIFF and Wave.  So,
basically, single settings which have multiple flags to set them (output
format, sample size) are treated as if all the flags had occurred on a
single command-line.

Also, some options should probably be cumalative.  If --opcode-lib is
currently specified in two places, the last one prevails.  I think that ALL
of them should be strung together so that you can put a default set of
libraries in your .csoundrc file, and then add additional libraries on the
commandline or in the CSD as needed.

I do not think that simply running argdecode again on the command-line opts
is a good idea.  A better solution would be to create a data structure for
storing all of the options and make an instance of that structure for each
of the separate option-parsing passes.  After that is all done, there should
be a function which looks at all of these structures and builds the final
set of options following the precedence rules, overriding or accumalating
settings as appropriate.  A final error reporting pass might be needed in
the end.

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/
 

On 2/18/05 6:19 AM, Istvan Varga  etched in stone:

> One problem remains: CSD options are read last, but actually the
> command line should override the CSD, and not the other way, as it
> currently is. This would require a second pass of parsing command
> line options after the CSD has been read, but not sure if it is safe
> to do.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> For example, if there is -A in .csoundrc and -W in the CSD, then you get an
> error saying that the output format cannot be both AIFF and Wave.  So,
> basically, single settings which have multiple flags to set them (output
> format, sample size) are treated as if all the flags had occurred on a
> single command-line.

I am aware of this (and find the error message very annoying), but it
should be easy to solve: the flag that has been specified last should
take effect (i.e. -J -W -A -h is the same as just -h). And the use of
libsndfile makes all these weird format checks obsolete, as it will
detect invalid file and sample format combinations anyway.

> Also, some options should probably be cumalative.  If --opcode-lib is
> currently specified in two places, the last one prevails.  I think that ALL
> of them should be strung together so that you can put a default set of
> libraries in your .csoundrc file, and then add additional libraries on the
> commandline or in the CSD as needed.

The library names should be added to a database, but it is difficult to
filter out duplicate entries. --opcode-lib is rarely needed, though, as you
can just have all plugins to be loaded by default in OPCODEDIR.

> I do not think that simply running argdecode again on the command-line opts
> is a good idea.  A better solution would be to create a data structure for
> storing all of the options and make an instance of that structure for each
> of the separate option-parsing passes.  After that is all done, there should
> be a function which looks at all of these structures and builds the final
> set of options following the precedence rules, overriding or accumalating
> settings as appropriate.  A final error reporting pass might be needed in
> the end.

Sounds quite complicated, and needs to solve the same problems as a
version of argdecode that is safe to run multiple times. This mainly
involves the special treatment of --opcode-lib (are there any other
options that should accumulate rather than override ?), and removal
of side-effects from argdecode.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The latest Csound5 CVS has many fixes and improvements related to
these issues, you may want to test how well it works.

Anthony Kozar wrote:

> I have been thinking about this problem recently and it is more complicated
> than it looks.  Not only do the command-line options get overridden by those
> in the CSD but some options do not work "correctly" when specified in
> multiple places.
> 
> For example, if there is -A in .csoundrc and -W in the CSD, then you get an
> error saying that the output format cannot be both AIFF and Wave.  So,
> basically, single settings which have multiple flags to set them (output
> format, sample size) are treated as if all the flags had occurred on a
> single command-line.
> 
> Also, some options should probably be cumalative.  If --opcode-lib is
> currently specified in two places, the last one prevails.  I think that ALL
> of them should be strung together so that you can put a default set of
> libraries in your .csoundrc file, and then add additional libraries on the
> commandline or in the CSD as needed.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net