This is the C runtime library getenv call (stdlib.h).

Original Message:
-----------------
From: steven stevenyi@csounds.com
Date: Thu, 04 Dec 2003 13:22:18 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3639] Environment Variables


Hi all,

Is there a way through the host API or GLOBALS/ENVIRON struct to get 
SFDIR, SSDIR, SADIR, etc.?

thanks,
steven


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

I think I'll go ahead and just use getenv and ifdef for "/" or "\" in 
filenames as isfullpath, catpath, and other functions from filopen.c are 
not in GLOBALS/ENVIRON either.  (These should probably be added, yes?)

I'm trying to get the fluidOpcodes opcode lib with csound4 to load 
soundFonts from SADIR or SFDIR and for some reason when trying:

fluid->h.insdshead->csound->sfdirpath
fluid->h.insdshead->csound->sadirpath

I'm getting null pointers.  (It's very possible a c-coding fault of mine 
though).

I also don't want to access data directly as I won't be able to get them 
in future versions once more functions are added. 

steven



gogins@pipeline.com wrote:

>This is the C runtime library getenv call (stdlib.h).
>
>  
>

i am to blame for that stuff in the api, and in
in my original code there are csoundSetEnv(), csoundGetEnv(), and
csoundClearEnv() functions, but they were not included in canonical
because i think the required a re#define of getenv()

anyway, i would like to consider rethinking the entire usage of paths in
csound5.  it would much preferable i think to have an unlimited number of
paths and the ability to search all of them when not found in the primary
default paths.  the fileopen.c functions sort of do this already, but i
seem to remember this is only used for soundfiles and things like file
writing opcodes dont use it.

-m






On Thu, 4 Dec 2003, steven wrote:

> I think I'll go ahead and just use getenv and ifdef for "/" or "\" in
> filenames as isfullpath, catpath, and other functions from filopen.c are
> not in GLOBALS/ENVIRON either.  (These should probably be added, yes?)
>
> I'm trying to get the fluidOpcodes opcode lib with csound4 to load
> soundFonts from SADIR or SFDIR and for some reason when trying:
>
> fluid->h.insdshead->csound->sfdirpath
> fluid->h.insdshead->csound->sadirpath
>
> I'm getting null pointers.  (It's very possible a c-coding fault of mine
> though).
>
> I also don't want to access data directly as I won't be able to get them
> in future versions once more functions are added.
>
> steven
>
>
>
> gogins@pipeline.com wrote:
>
> >This is the C runtime library getenv call (stdlib.h).
> >
> >
> >
>
>

>anyway, i would like to consider rethinking the entire usage of paths in
>csound5.  it would much preferable i think to have an unlimited number of
>paths and the ability to search all of them when not found in the primary
>default paths.  the fileopen.c functions sort of do this already, but i
>seem to remember this is only used for soundfiles and things like file
>writing opcodes dont use it.
>  
>
Do you have anything in mind yet?  I was thinking about how Java and 
Python do classpath's and thought they'd make good models.  How about 
CSOUND_PATH as an environment variable?  Also a new csoundFindFile()  
utility function for the host/opcode API's to automate searching the paths:

(Pseudo-code)

char * csoundFileFile(char * fileName) {
    char * returnPath = NULL;
   if(fileExists(fileName)) {
       return returnPath = fileName;
   } else {
       for(dir in CSOUND_PATH) { /* check all directories listed in 
CSOUND_PATH */
           tempPath = dir + dir_separator + fileName;
           if(fileExists(tempPath)) {
             returnPath =  tempPath;
             break;
          }

       }
    }
    return NULL;
}


-CSOUND_PATH would by default be defined as an environment variable
-it could be replaced on the commandline to csound:

csound --csound-path="..." 

-it can be appended to with:

csound --csound-path="$CSOUND_PATH, ... "

This is very java-like and I've never really had problems with this.  To 
go along with this, I'd suggest a new "#import" as part of the 
orc-parser.  This makes csound more programming like for libraries.  The 
idea is in your orc (or the CsInstruments section of a CSD), have:

#import "fluidOpcodes"
#import "lorisOpcodes"

*WITHOUT* library extension name.  On windows, csound would dll when 
looking for the library, on linux look for .so's, etc.  (I've recently 
found that when working on the same work file on windows and linux that 
having to change the --opcode-lib="" string for reasons of "\" versus 
"/" as well as .dll versus .so to be tedious).  Csound then would not 
import the library unless explicitly asked to do so within the ORC/CSD. 
  Also, it would make it easier to distribute CSD's and ORC's across 
platforms and embed it's dependencies within the file. 

Something else I would like to propose (though not as strongly) is a 
CSOUND_HOME variable.  A Csound distribution would create a csound 
directory and have these subdirectories:

csound/bin
csound/lib
csound/doc
csound/opcodeLib
csound/opcodeDoc

and the CSOUND_HOME would point to that csound root dir.  The opcodeLib 
and opcodeDoc would be a standardized place to install libraries.  The 
opcodeDoc directory could mirror opcodeLib, such that if you installed:

opcodeLib/effects/myEffectsOpcodeLib.so

then the doc for it would be:

opcodeLib/effects/myEffectsOpcodeLib.html



Any thoughts on all of this? 

steven

> >anyway, i would like to consider rethinking the entire usage of paths in
> >csound5.  it would much preferable i think to have an unlimited number of

> Do you have anything in mind yet?  I was thinking about how Java and
> Python do classpath's and thought they'd make good models.  How about
> CSOUND_PATH as an environment variable?  Also a new csoundFindFile()
> utility function for the host/opcode API's to automate searching the paths:

yes that is basically waht i was thinking, except have an internal linked
list of paths. i dont know if i agree with dr. b. about searching
subdirectories automatically, that could get tedious.. and probably would
still want to search for soundfiles in sfdir first,  anal files in sadir
first, etc..  i could also see maybe adding a callback to a host asking to
find the file if csound itself cant find it


> #import "fluidOpcodes"
> #import "lorisOpcodes"
>
> *WITHOUT* library extension name.  On windows, csound would dll when

fine by me

> and the CSOUND_HOME would point to that csound root dir.  The opcodeLib

i still would like a directory that is an auto-include for opcode libs AND
orchestras, allowing for #include/#import to be needed only when needing
something living outside that folder. especially if a lot of old opcodes
are being trimmed off to externals, i could see a lot of head scratching
trying to figure out why an orc isnt working and all it is is a missing
#include...


-m

You need to ensure that sssfinit is called in your init function.
Look at sfont.c or similar.  Those fields are only filled in sssfinit
and that is not called in main.  Perhaps it shoudl be...
==John ffitch

>>>>> "steven" == steven   writes:

 steven> I'm trying to get the fluidOpcodes opcode lib with csound4 to load 
 steven> soundFonts from SADIR or SFDIR and for some reason when trying:

 fluid-> h.insdshead->csound->sfdirpath
 fluid-> h.insdshead->csound->sadirpath

 steven> I'm getting null pointers.  (It's very possible a c-coding fault of mine 
 steven> though).

Hi John,

I took a grep a around the code and didn't find sssfinit in sfont.c,
only  in oload.c::oload() and somewhere in sndinfo.c and soundin.c.  It
did take me a bit by surprise that sfdirpath and ssdirpath weren't being
set in the GLOBALS * (using csound4 for this opcode lib).  

It makes sense to me that opcode libs shouldn't have to call ssfinit
before grabbing the values.  In regards to my other email, I would
rather prefer now to have a function to find a file in csound's paths
(SADIR, SFDIR, etc.) as well as the proposed CSOUND_PATH, as such a
utility function seems less of a burden to opcode builders than having
to replicate file finding code for each opcode. 

I'll be writing a csoundFindFilePath() function tomorrow or Monday and
will post here to get a consensus on its inclusion;  if it seems like a
useful function I'll commit it to csound5 cvs.

steven


On Sat, 2003-12-06 at 02:02, jpff@codemist.co.uk wrote:
> You need to ensure that sssfinit is called in your init function.
> Look at sfont.c or similar.  Those fields are only filled in sssfinit
> and that is not called in main.  Perhaps it shoudl be...
> ==John ffitch

>>>>> "stevenyi" == stevenyi   writes:

 stevenyi> Hi John,
 stevenyi> I took a grep a around the code and didn't find sssfinit in sfont.c,
 stevenyi> only  in oload.c::oload() and somewhere in sndinfo.c and soundin.c.  It
 stevenyi> did take me a bit by surprise that sfdirpath and ssdirpath weren't being
 stevenyi> set in the GLOBALS * (using csound4 for this opcode lib).  

Sorry mistyped: 
grep -n -e sssfinit *.h *.c /dev/null
prototyp.h:56:void sssfinit(void);
filopen.c:36:void sssfinit(void)
oload.c:302:extern  void    cpsoctinit(void), reverbinit(void), sssfinit(void);
oload.c:581:    sssfinit();
sndinfo.c:42:    sssfinit();
soundin.c:433:    sssfinit();                    /* stand-alone init of SFDIR etc. */


 stevenyi> It makes sense to me that opcode libs shouldn't have to call ssfinit
 stevenyi> before grabbing the values.
I am reporting what happens not what should happen.  In CS5 no doubt
this will be corrected.

 stevenyi>                              In regards to my other email, I would
 stevenyi> rather prefer now to have a function to find a file in csound's paths
 stevenyi> (SADIR, SFDIR, etc.) as well as the proposed CSOUND_PATH, as such a
 stevenyi> utility function seems less of a burden to opcode builders than having
 stevenyi> to replicate file finding code for each opcode. 

 stevenyi> I'll be writing a csoundFindFilePath() function tomorrow or Monday and
 stevenyi> will post here to get a consensus on its inclusion;  if it seems like a
 stevenyi> useful function I'll commit it to csound5 cvs.

==John ffitch