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");
/* 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 = ".";
sep = "\\";
sep = "/";
/* 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:
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.
> ** 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.
> -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
> 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.
> Specifying a full pathname _always_ stops Csound from searching anywhere
> 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
>> 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.
> Csound-devel mailing list