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 
>Sent: May 16, 2007 12:01 PM
>To: Csound Developer list 
>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@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
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@lists.sourceforge.net

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

-------------------------------------------------------------------------
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@lists.sourceforge.net

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



-------------------------------------------------------------------------
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@lists.sourceforge.net

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@lists.sourceforge.net

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.


-------------------------------------------------------------------------
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@lists.sourceforge.net

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  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
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@lists.sourceforge.net

Stéphane, 

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 to
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éphane 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 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.


-------------------------------------------------------------------------
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@lists.sourceforge.net

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@lists.sourceforge.net

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
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@lists.sourceforge.net

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  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
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@lists.sourceforge.net