Csound

Michael Gogins wrote on 5/16/07 10:37 AM:

> I agree with John. This needs more discussion.
> 
> In my experience, the #1 question for Windows users of Csound is, "How do I
> set an environment variable?" This is something most Windows users never need
> to do.

I hope that I am not being misunderstood.  I am not proposing adding a new
environment variable that would need to be set by users.  The proposal for
HOSTOUTDIR is for a path variable set via the API that would allow the host
application to specify an output directory for files that do not already
have a "default location".  HOSTOUTDIR would _not_ be read from the current
shell environment.

Thus, commandline Csound would be unaffected.  But hosts could be made more
user-friendly by automatically setting HOSTOUTDIR to the same location as
the orchestra or score for example.

> Also, it is a frequent request to developers, and not only from Windows users,
> that Csound function without any environment variable settings at all. I would
> prefer this myself.

I think it would still be unnecessary to set any environment variables with
my proposed changes.  (OPCODEDIR excepted on some platforms).

> I suggest that files be located as follows:
> 
> 1) Try using the absolute path.
> 2) Try using the environment variables.
> 3) Try using hard-coded paths (this is what would work if no environment
> variables were used). It is a question whether these paths should be relative
> to (a) the root directory, (b) the Csound bin directory, or (c) the current
> working directory.
> 4) Try the current working directory itself.

Csound already has a similar and quite flexible system like this.  If you
look over the code in envvar.c, you will see that the functions
csoundFindInputFile() and csoundFindOutputFile() already take care of most
or all of this.  These functions are called by the csound->FileOpen2()
function pointer.

The problem is that some opcodes are not using the already existing
mechanism of csound->FileOpen2() to open their files.  They are using
fopen() directly and are not utilizing the flexibility of
csound->FileOpen2() and thus are not behaving in a consistent manner with
the rest of Csound.

I am actually trying to introduce more consistency to the way that opcodes
open files while simultaneously solving a problem that affects host
applications.  (So perhaps there are really two separate issues here).

Anthony

Thanks for the clarification. If the purpose is internal then it is fine with me.

I certainly agree with your goal of making Csound's behavior more consistent.

I do suggest that hard-coded paths exist, in a consistent manner, for all environment variable-settable paths. Again, the question is what the default path is relative to: current working directory, Csound bin directory, home directory, and indeed is this the same for all variables?

Regards,
Mike

-----Original Message-----
>From: Anthony Kozar <anthonykozar@...>
>Sent: May 16, 2007 12:01 PM
>To: Csound Developer list <csound-devel@...>
>Subject: Re: [Cs-dev] Proposal for changes to opening certain files
>
>Michael Gogins wrote on 5/16/07 10:37 AM:
>
>> I agree with John. This needs more discussion.
>> 
>> In my experience, the #1 question for Windows users of Csound is, "How do I
>> set an environment variable?" This is something most Windows users never need
>> to do.
>
>I hope that I am not being misunderstood.  I am not proposing adding a new
>environment variable that would need to be set by users.  The proposal for
>HOSTOUTDIR is for a path variable set via the API that would allow the host
>application to specify an output directory for files that do not already
>have a "default location".  HOSTOUTDIR would _not_ be read from the current
>shell environment.
>
>Thus, commandline Csound would be unaffected.  But hosts could be made more
>user-friendly by automatically setting HOSTOUTDIR to the same location as
>the orchestra or score for example.
>
>> Also, it is a frequent request to developers, and not only from Windows users,
>> that Csound function without any environment variable settings at all. I would
>> prefer this myself.
>
>I think it would still be unnecessary to set any environment variables with
>my proposed changes.  (OPCODEDIR excepted on some platforms).
>
>> I suggest that files be located as follows:
>> 
>> 1) Try using the absolute path.
>> 2) Try using the environment variables.
>> 3) Try using hard-coded paths (this is what would work if no environment
>> variables were used). It is a question whether these paths should be relative
>> to (a) the root directory, (b) the Csound bin directory, or (c) the current
>> working directory.
>> 4) Try the current working directory itself.
>
>Csound already has a similar and quite flexible system like this.  If you
>look over the code in envvar.c, you will see that the functions
>csoundFindInputFile() and csoundFindOutputFile() already take care of most
>or all of this.  These functions are called by the csound->FileOpen2()
>function pointer.
>
>The problem is that some opcodes are not using the already existing
>mechanism of csound->FileOpen2() to open their files.  They are using
>fopen() directly and are not utilizing the flexibility of
>csound->FileOpen2() and thus are not behaving in a consistent manner with
>the rest of Csound.
>
>I am actually trying to introduce more consistency to the way that opcodes
>open files while simultaneously solving a problem that affects host
>applications.  (So perhaps there are really two separate issues here).
>
>Anthony
> 
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@...
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Anthony Kozar wrote:
..
> 
> I hope that I am not being misunderstood.  I am not proposing adding a new
> environment variable that would need to be set by users.  The proposal for
> HOSTOUTDIR is for a path variable set via the API that would allow the host
> application to specify an output directory for files that do not already
> have a "default location".  HOSTOUTDIR would _not_ be read from the current
> shell environment.
> 

I think it is important that Csound itsel deasl as little as posisble 
with external environment issues. This is more properly the domain of 
the host application. On Windows, the idiomatic place to store path and 
other environment-related information is in the Registry; on the Mac it 
would be in a  Preferences file and/or in "Application Support" etc. The 
Csound engine itself needs to be as system-agnostic as possible, with 
the host supplying search paths to the engine via the API, which should 
employ a minimum set of defaults. In this regard, even a command-line 
wrapper is a host; so that it would query enviornment variables, the 
Registry, the Perferences file, or whatever, and the Csound engine 
itself would not search for these things at all. This way, a host can, 
if it so wishes, supply distinct environments to multiple instances of 
Csound.

Richard Dobson

Richard Dobson wrote on 5/16/07 12:13 PM:

> I think it is important that Csound itsel deasl as little as posisble
> with external environment issues. This is more properly the domain of
> the host application. On Windows, the idiomatic place to store path and
> other environment-related information is in the Registry; on the Mac it
> would be in a  Preferences file and/or in "Application Support" etc. The
> Csound engine itself needs to be as system-agnostic as possible, with
> the host supplying search paths to the engine via the API, which should
> employ a minimum set of defaults. In this regard, even a command-line
> wrapper is a host; so that it would query enviornment variables, the
> Registry, the Perferences file, or whatever, and the Csound engine
> itself would not search for these things at all. This way, a host can,
> if it so wishes, supply distinct environments to multiple instances of
> Csound.

Yes, I agree completely with this logic.  One of things that I am trying to
do is give the host more control over these issues.  I believe that the
current system is not too bad in these regards.

Currently, Csound's "environment variables" are internal strings **.  These
may be set or appended to by a host or from the commandline with the flag
--env (see csoundParseEnv() envvar.c).  I believe that Istvan implemented
this system (at my request) so that platforms without real environment
variables could continue to work correctly.  There are internal functions
csoundSetEnv(), csoundAppendEnv(), and csoundPrependEnv() for modifying
these internal variables.  And csoundInitEnv() is called during
csoundPreCompile() to read the variables from the operating system on
systems where they exist.

This last bit is one of the only parts that is not consistent with Richard's
viewpoint but it could be made so by moving the querying of the system
environment to the commandline host.  The other part that IMHO is not
consistent is the use of the system "current directory" concept.  I propose
a possible solution to this latter issue below.

I had believed that csoundSetEnv() and csoundAppendEnv() were public API
functions but they are not.  Perhaps they should be so that hosts do not
have to use the --env flag.  (There is a public function
csoundSetGlobalEnv() but that does not work on a per-instance basis, so I am
not sure why it is there).

Of course, the reason that I have brought all of this up is because some
parts of Csound ignore the system in envvar.c entirely and just read or
write to the current directory.  Since a host application cannot control
this on a per-instance basis, this is "bad".

So, at a minimum, I think that the opcodes and other parts of Csound that
call fopen() directly need to be cleaned up to use csound->FileOpen2()
instead.  In doing so, it is possible to specify a search path for these
changed opcodes or to specify an empty path.  I think that these opcodes
should be assigned search paths consistent with similar opcodes (or with
their purposes if different).

I was also suggesting that some opcodes (like the dumpk family) that already
use csound->FileOpen2() with an empty search path might be modified to have
a non-empty search path consistent with other similar opcodes.

If others think that adding or modifying search paths for existing opcodes
is a problem -- or that we need a better solution for when SFDIR, etc. are
undefined -- then I can suggest another more comprehensive solution to the
issue of files ending up in the "current directory" when that is
inappropriate for a host application:

A new API function (or functions) could be added for setting a per-instance
"working directory" (or an "input directory" and an "output directory"?).
csoundFindInputFile() and csoundFindOutputFile() would be modified so that
when this internal variable is set, ALL file operations that would affect
the current directory will use the specified directory instead.  If the
variable is not set, Csound would function as it does now.
csound->FileOpen2() would still have to be used in place of fopen() in the
places that I have previously described.

Thanks for this very productive discussion :)

Anthony

** A truly platform-agnostic system would not use pathnames stored as
strings, but a platform-defined datatype for locating files.  MacOS 9 does
not work 100% reliably when using pathnames.

On Wed, 2007-16-05 at 10:37 -0400, Michael Gogins wrote:
> I agree with John. This needs more discussion.
> 
> In my experience, the #1 question for Windows users of Csound is, "How do I set an environment variable?" This is something most Windows users never need to do.
> 

+1 on the above comment. I vividly remember getting frustrated with that
when I first started playing with csound many years ago. Defaults would
be good with environment variables available for "power users". 

Iain

+2

Art Hunkins

----- Original Message ----- 
From: "iain duncan" <iainduncan@...>
To: "Michael Gogins" <gogins@...>; "Developer discussions"
<csound-devel@...>
Sent: Wednesday, May 16, 2007 2:56 PM
Subject: Re: [Cs-dev] Proposal for changes to opening certain files


> On Wed, 2007-16-05 at 10:37 -0400, Michael Gogins wrote:
> > I agree with John. This needs more discussion.
> >
> > In my experience, the #1 question for Windows users of Csound is, "How
do I set an environment variable?" This is something most Windows users
never need to do.
> >
>
> +1 on the above comment. I vividly remember getting frustrated with that
> when I first started playing with csound many years ago. Defaults would
> be good with environment variables available for "power users".
>
> Iain
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Michael Gogins wrote:
> Thanks for the clarification. If the purpose is internal then it is fine with me.
> 
> I certainly agree with your goal of making Csound's behavior more consistent.
> 
> I do suggest that hard-coded paths exist, in a consistent manner, for all environment variable-settable paths. Again, the question is what the default path is relative to: current working directory, Csound bin directory, home directory, and indeed is this the same for all variables?
> 
> Regards,
> Mike

I would suggest the current directory or the bin directory, but 
definitely not the home directory, since it is unique to the system, 
while the interest of not relying on environment variables is that 
multiple csound instances can coexist happily in the same system.

as one of the persons regularly complaining about environment variables, 
I should say that I am not opposed to them, only that a mechanism should 
be provided to avoid using them if desired. for example, a command-line 
flag telling csound to ignore all environment variables and instead use 
hard-coded paths or other command-line settings would be enough in my view.


regards,

Stef

Stéphane Rollandin wrote:
..
> as one of the persons regularly complaining about environment variables, 
> I should say that I am not opposed to them, only that a mechanism should 
> be provided to avoid using them if desired. for example, a command-line 
> flag telling csound to ignore all environment variables and instead use 
> hard-coded paths or other command-line settings would be enough in my view.
> 

There is of course a very simple default that can be decided, especially 
when working from the command-line, that ~everything~ is read and 
written relative to the current directory. No environment variables 
required. This has the great virtue that it then works the way 99.9% of 
all command-line programs work!

Richard Dobson

I am not sure what you mean by "hard-coded paths", Michael.  Certainly, if
neither the user nor the host application sets any of the environment
variables, then Csound defaults to the current directory for reading and
writing files.  In addition, a feature was recently added that adds the
directory of the score and orchestra (or CSD) files to the SSDIR, SADIR, and
MFDIR paths.  (Plus, INCDIR in the case of a CSD).  This feature can be
turned off.  Csound also searches for orchestra or score include files
relative to the orchestra or score file path.

All of these defaults make a good deal of sense (to me).  Also, the ability
for the user or host to set up additional search paths is very useful.
(These are always optional, so I am not sure why people don't like them).

What I am not happy about is that some files can _only_ be written to the
current directory.  In order to provide a complete solution for hosts, we
need to either assign additional _optional_ search paths to these files OR
we need an API function that allows the host to set a "working directory" on
a per-instance basis.

I am now leaning towards the comprehensive API function solution. ** I think
that if set, this working directory should replace all uses of the system's
idea of the current directory.  It would be up to the host to decide what
makes sense for this setting (or allow the user to choose somehow).  All of
the other searching mechanisms described in my first paragraph above would
still apply, of course.  Examples of the proposed behavior are below.

Can we arrive at some consensus about a solution?  I would like to finish
implementing the FileOpen callback, and some of these issues affect my work.

Thanks.

Anthony

** Even if we go with the API function, I think sfload and probably ftload
should have their search paths changed to something like SFDIR;SSDIR.  Not
being able to load soundfonts from anywhere but the current or working
directory is a pain.
 
Examples:

-o mysound.aiff is specified in the arguments and the host has set the
working directory to /myfiles.  If SFDIR is defined, mysound.aiff will be
written to SFDIR, otherwise it will be written to /myfiles.

An orchestra contains the line:  afile  diskin  "mysample.wav", ...
The search path set by the diskin opcode is "SFDIR;SSDIR".  This means that
if the file is not in the current directory, then it will be looked for in
SSDIR, and if not found there, in SFDIR.  Csound automatically appends the
orchestra and score directories to SSDIR so that they are searched before
other locations.  If the host application sets a working directory, then the
search would instead be:
        host-set working directory
        orchestra's directory
        score's directory
        SSDIR
        SFDIR

When the --keep-sorted-score option is specified, Csound writes the sorted
score to a file named "score.srt" instead of a temporary file.  If there is
no host-supplied working directory, then this file will be written to the
current directory (however that is determined by the OS).  If the host sets
a workind directory, then score.srt will be written there instead.

Notes:

Specifying a full pathname _always_ stops Csound from searching anywhere
else.

Searching is never applied to the orchestra, score, or CSD filenames.

Other files specified on the commandline using the -o, -i, -F, -@, and -x
flags will have searching and/or host-working-directory-replacement applied
to them.  (All of them except -x currently have search paths).

Michael Gogins wrote on 5/16/07 12:08 PM:

> Thanks for the clarification. If the purpose is internal then it is fine with
> me.
> 
> I certainly agree with your goal of making Csound's behavior more consistent.
> 
> I do suggest that hard-coded paths exist, in a consistent manner, for all
> environment variable-settable paths. Again, the question is what the default
> path is relative to: current working directory, Csound bin directory, home
> directory, and indeed is this the same for all variables?

Anthony Kozar wrote:
> All of these defaults make a good deal of sense (to me).  Also, the ability
> for the user or host to set up additional search paths is very useful.
> (These are always optional, so I am not sure why people don't like them).

I can give you two reasons why I unhappy with the current state of affairs:
1) OPCODEDIR64 is not optional
2) if I install csound on Windows (with an installer, since I have no 
choice), then the variables are being set. and when set, they mess up 
the other csound installations I may have on my system.

so not only should the variables be optional (as they mostly, but not 
fully, are) but we should also be able to ignore them when they do exis, 
which is not the case now.

an example: if I want to create a distribution of [muO + csound-x + 
csound] for Windows users (a draft for such a thing exists here: 
http://www.zogotounga.net/surmulot/surmulot.html), then I have to worry 
that such users may have csound already installed, which would break the 
settings I provide for my embedded csound.


hope this helps explaining the problem


cheers,

Stef



PS: did I state somewhere that I would very much have a csound distro 
for Windows with no installer ?




PPS: Mrs Jones was very healthy when someone offered her an installer. 
she got sick and died in two days.




PPPS: prehistoric paintings on the walls in a French cave showed 
evidence that neanderthal people somehow knew dinosaurs where killed by 
badly configured installers.

I think that what Anthony is suggesting makes a lot of sense. In my
opinion a stronger version, HOSTIODIR, is desirable. This would save a
lot of dancing around current/future environment variables, as well as
fixing the OS9 issue that he describes. If set, the variable could
make it possible to do things this way (excuse the bad pseudo code):

projdir =  "directory_defined_by_host";
rootdir = getenv("HOSTIODIR");
if (!rootdir)
{
/* Sorry Anthony, if I understand correctly, this is the sort of thing
that is problematic. On systems where this is a problem, the Csound
installer would create the variable? */
rootdir = "."; 
}
#ifdef WIN32
sep = "\\";
#else
sep = "/";
#endif
/* Yes, strcat is probably deprecated. Anyway. */
strcat (rootdir, sep);
strcat (rootdir, projdir);

All files created by the host could be written to projdir, and all
needed files could be searched for relative to HOSTIODIR, otherwise
use existing search paths. This would make the task of defining a host
project directory containing all files needed by that project (and
accessing them using relative paths) much easier, and could streamline
things so that we might see:

$HOSTIODIR/blue
$HOSTIODIR/lettuce
$HOSTIODIR/and_c

Jonathan.

Anthony Kozar <anthonykozar@...> writes:

> I am not sure what you mean by "hard-coded paths", Michael.  Certainly, if
> neither the user nor the host application sets any of the environment
> variables, then Csound defaults to the current directory for reading and
> writing files.  In addition, a feature was recently added that adds the
> directory of the score and orchestra (or CSD) files to the SSDIR, SADIR, and
> MFDIR paths.  (Plus, INCDIR in the case of a CSD).  This feature can be
> turned off.  Csound also searches for orchestra or score include files
> relative to the orchestra or score file path.
>
> All of these defaults make a good deal of sense (to me).  Also, the ability
> for the user or host to set up additional search paths is very useful.
> (These are always optional, so I am not sure why people don't like them).
>
> What I am not happy about is that some files can _only_ be written to the
> current directory.  In order to provide a complete solution for hosts, we
> need to either assign additional _optional_ search paths to these files OR
> we need an API function that allows the host to set a "working directory" on
> a per-instance basis.
>
> I am now leaning towards the comprehensive API function solution. ** I think
> that if set, this working directory should replace all uses of the system's
> idea of the current directory.  It would be up to the host to decide what
> makes sense for this setting (or allow the user to choose somehow).  All of
> the other searching mechanisms described in my first paragraph above would
> still apply, of course.  Examples of the proposed behavior are below.
>
> Can we arrive at some consensus about a solution?  I would like to finish
> implementing the FileOpen callback, and some of these issues affect my work.
>
> Thanks.
>
> Anthony
>
> ** Even if we go with the API function, I think sfload and probably ftload
> should have their search paths changed to something like SFDIR;SSDIR.  Not
> being able to load soundfonts from anywhere but the current or working
> directory is a pain.
>  
> Examples:
>
> -o mysound.aiff is specified in the arguments and the host has set the
> working directory to /myfiles.  If SFDIR is defined, mysound.aiff will be
> written to SFDIR, otherwise it will be written to /myfiles.
>
> An orchestra contains the line:  afile  diskin  "mysample.wav", ...
> The search path set by the diskin opcode is "SFDIR;SSDIR".  This means that
> if the file is not in the current directory, then it will be looked for in
> SSDIR, and if not found there, in SFDIR.  Csound automatically appends the
> orchestra and score directories to SSDIR so that they are searched before
> other locations.  If the host application sets a working directory, then the
> search would instead be:
>         host-set working directory
>         orchestra's directory
>         score's directory
>         SSDIR
>         SFDIR
>
> When the --keep-sorted-score option is specified, Csound writes the sorted
> score to a file named "score.srt" instead of a temporary file.  If there is
> no host-supplied working directory, then this file will be written to the
> current directory (however that is determined by the OS).  If the host sets
> a workind directory, then score.srt will be written there instead.
>
> Notes:
>
> Specifying a full pathname _always_ stops Csound from searching anywhere
> else.
>
> Searching is never applied to the orchestra, score, or CSD filenames.
>
> Other files specified on the commandline using the -o, -i, -F, -@, and -x
> flags will have searching and/or host-working-directory-replacement applied
> to them.  (All of them except -x currently have search paths).
>
> Michael Gogins wrote on 5/16/07 12:08 PM:
>
>> Thanks for the clarification. If the purpose is internal then it is fine with
>> me.
>> 
>> I certainly agree with your goal of making Csound's behavior more consistent.
>> 
>> I do suggest that hard-coded paths exist, in a consistent manner, for all
>> environment variable-settable paths. Again, the question is what the default
>> path is relative to: current working directory, Csound bin directory, home
>> directory, and indeed is this the same for all variables?
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

St=E9phane,=20

I understand the frustration associated with OPCODEDIR -- which is why I
made the plugin directory on MacOS 9 relative to the Csound installation --
but OPCODEDIR does not really play into what I am discussing or wanting to
change.  This is a completely separate issue in my mind.

I am talking about user data files that get read or written by Csound, and
how Csound chooses where to look for or put these files.

Regarding OPCODEDIR, other people will have to come up with solutions for
their own platforms that make sense.  On MacOS 9, Csound uses Mac-only
functions to discover the location of the currently running process (host
application).  Then it loads a specific resource within that host
application to discover where the plugins are located.  This allows every
host app and every installation to have its own plugin directory.  I also
programmed a system-wide "backup" location to search in case a user wants t=
o
share plugins with multiple installations.

How something similar could be done on other systems, I cannot answer.  A
host may be able to use the csoundSetGlobalEnv() call to override OPCODEDIR
-- I am not sure.

Anthony

St=E9phane Rollandin wrote on 5/17/07 4:00 AM:

> Anthony Kozar wrote:
>> All of these defaults make a good deal of sense (to me).  Also, the abil=
ity
>> for the user or host to set up additional search paths is very useful.
>> (These are always optional, so I am not sure why people don't like them)=
.
>=20
> I can give you two reasons why I unhappy with the current state of affair=
s:
> 1) OPCODEDIR64 is not optional
> 2) if I install csound on Windows (with an installer, since I have no
> choice), then the variables are being set. and when set, they mess up
> the other csound installations I may have on my system.
>=20
> so not only should the variables be optional (as they mostly, but not
> fully, are) but we should also be able to ignore them when they do exis,
> which is not the case now.
>=20
> an example: if I want to create a distribution of [muO + csound-x +
> csound] for Windows users (a draft for such a thing exists here:
> http://www.zogotounga.net/surmulot/surmulot.html), then I have to worry
> that such users may have csound already installed, which would break the
> settings I provide for my embedded csound.

Jonathan Murphy wrote on 5/17/07 6:33 AM:

> projdir =  "directory_defined_by_host";
> rootdir = getenv("HOSTIODIR");

Actually, I am not suggesting this at all.  The host working directory would
_not_ be retrieved from a system (shell) environment variable by Csound
using getenv() (the host can choose to get the path from whereever it
wants).  It would be set from host application code in this way:

char mydir[] = "/some/pathname/that/I/like"

result = csoundPreCompile(csound);
csoundSetHostWorkingDirectory(csound, mydir);
result = csoundCompile(csound, argc, argv);

The parameter mydir would only apply to this instance of CSOUND.

This idea has changed somewhat from my original proposal for the HOSTOUTDIR
variable, thanks to the input from others.  I now think that having only an
API call (with whatever name seems best) would be a better way to go.

Anthony

I would only add to this discussion that I am loving the new default  
behavior which has Csound
searching for samples, analysisfiles, scanned matrix files, etc in  
the current working directory.
it has made my teaching and my working so much easier.  in a sense, i  
don't have to worry about
paths at all with that default behavior - just put what I use in the  
folder with the .csd for the composition.

-dB

On May 17, 2007, at 10:59 AM, Anthony Kozar wrote:

> Jonathan Murphy wrote on 5/17/07 6:33 AM:
>
>> projdir =  "directory_defined_by_host";
>> rootdir = getenv("HOSTIODIR");
>
> Actually, I am not suggesting this at all.  The host working  
> directory would
> _not_ be retrieved from a system (shell) environment variable by  
> Csound
> using getenv() (the host can choose to get the path from whereever it
> wants).  It would be set from host application code in this way:
>
> char mydir[] = "/some/pathname/that/I/like"
>
> result = csoundPreCompile(csound);
> csoundSetHostWorkingDirectory(csound, mydir);
> result = csoundCompile(csound, argc, argv);
>
> The parameter mydir would only apply to this instance of CSOUND.
>
> This idea has changed somewhat from my original proposal for the  
> HOSTOUTDIR
> variable, thanks to the input from others.  I now think that having  
> only an
> API call (with whatever name seems best) would be a better way to go.
>
> Anthony
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

I'm sorry, I reread the thread and you had made this very clear
already. What you are actually suggesting makes a great deal more
sense, and I think that it's a great idea.

Jonathan.

Anthony Kozar <anthonykozar@...> writes:

> Jonathan Murphy wrote on 5/17/07 6:33 AM:
>
>> projdir =  "directory_defined_by_host";
>> rootdir = getenv("HOSTIODIR");
>
> Actually, I am not suggesting this at all.  The host working directory would
> _not_ be retrieved from a system (shell) environment variable by Csound
> using getenv() (the host can choose to get the path from whereever it
> wants).  It would be set from host application code in this way:
>
> char mydir[] = "/some/pathname/that/I/like"
>
> result = csoundPreCompile(csound);
> csoundSetHostWorkingDirectory(csound, mydir);
> result = csoundCompile(csound, argc, argv);
>
> The parameter mydir would only apply to this instance of CSOUND.
>
> This idea has changed somewhat from my original proposal for the HOSTOUTDIR
> variable, thanks to the input from others.  I now think that having only an
> API call (with whatever name seems best) would be a better way to go.
>
> Anthony
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel