While working on the FileOpen callback, I have found that a number of files
that Csound uses or creates are being opened with fopen() instead of
csound->FileOpen2() which can use a search path to find the file, and which
now provides useful feedback to hosts about opened files.  Opcodes really
should not use fopen(), so these cases should be changed to
csound->FileOpen2().  In some of the non-opcode cases, I think it would be
useful to extend the path searching mechanisms to give hosts more options.

The opcodes listed below only read or write files to the current directory
unless a full path is supplied.  This can be very inconvenient in a hosted
environment, therefore I suggest that they be changed to use the following
directory search paths:

ftload, ftloadk, ftsave, ftsavek    HOSTOUTDIR
pyexec                              INCDIR (or SFDIR;SSDIR;INCDIR ?)
sfload                              SFDIR;SSDIR
vstbankload, vstbanksave            HOSTOUTDIR
dumpk, dumpk2, dumpk3, dumpk4       SFDIR **

HOSTOUTDIR would be a new environment variable "internal" to Csound (i.e.
set via the API or --env commandline flag).  It would allow a host
application to specify another location for cases where previously a file
would have only been opened in the current directory.  It would function
similarly to SFDIR when writing a file since the search path is checked
before the current directory.  However, compatibility with the old behavior
would be maintained because HOSTOUTDIR would be undefined by default.

The proposed changes for pyexec and sfload would maintain compatibility as
well because the current directory is always checked before the search path
when reading a file.  In addition, by using csound->FileOpen2(), all of
these opcodes would gain the benefits of Csound's cross-platform pathname
conversion abilities.

The only opcodes that might function differently with existing orchestras
would be the dumpk family, but I think that this would be an improvement.
(And the files would still be found if read back in with readk[234]). **

Also, at present, the following files are always written to the current
directory:  "score.srt", "score.xtr", "cscore.out", "cscore.srt".  Writing
to the current directory can be a problem for hosts if the user does not
have permission to do so, if the concept of a "current directory" is not
very meaningful (MacOS 9), or if the host is being run from a locked disk (a
CD-ROM).  Therefore, I am proposing that these files also be written to
HOSTOUTDIR instead of the current directory when that path is defined.  (It
would make sense to me to include the EPS output file in this group as well,
but it is already being written to SFDIR).

I am going to start implementing these proposals unless someone objects.
Feedback on better alternatives would be appreciated as well.

Thanks.

Anthony

** Currently, readk and friends look in SFDIR;SSDIR for the files that may
have been created by dumpk[234].  But dumpk[234] do not write to either of
these.


-------------------------------------------------------------------------
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

Not totally happy about this.

A HOSTOUTDIR seems odd for ftload for example
When i use dumpk I definitely want it in the current directory
I am not sure about all the environment variables anyway -- may be a
Unix/Linux way of working but it seems to cause lots of problems on
Windows

I am just suggesting that we think about this first

==John ffitch

-------------------------------------------------------------------------
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

jpff wrote on 5/16/07 10:21 AM:

> Not totally happy about this.

I appreciate the feedback.  I am not sure that my proposal is ideal either.

> A HOSTOUTDIR seems odd for ftload for example

I suggested HOSTOUTDIR for ftload so that the opcode would look for these
files in the same location that I am proposing to have ftsave write them to.
I came up with the idea for HOSTOUTDIR for dealing with "score.srt", etc. so
that all existing Csound files and host code would continue to work in an
identical manner.

Other arrangements such as the "standard" writing to SFDIR and reading from
SFDIR;SSDIR would be fine with me as well.
 
> When i use dumpk I definitely want it in the current directory

dumk files would still go to the current directory under my proposal if
SFDIR is undefined.

> I am not sure about all the environment variables anyway -- may be a
> Unix/Linux way of working but it seems to cause lots of problems on
> Windows
> 
> I am just suggesting that we think about this first

The problem that I am trying to address is that some files are ONLY read or
written to/from the current directory unless one specifies a full path in
orchestra.  On MacOS 9, this means that those files always end up in the
host application's directory (which is very inconvenient and potentially
confusing to users).  A similar problem exists for host applications on
other platforms where the current directory for a GUI-launched program
defaults to some equally "useless" location.

I would like some mechanism for controlling where these files get written or
read from without having to specify paths in the orchestra.  Unfortunately,
having the host use chdir() on MacOS 9 has never been a good solution and it
is an especially bad solution when running multiple instances of Csound or
if Csound is embedded in some other environment (like PD).

I am certainly open to other suggestions.  The environment variables have
never been ideal on MacOS 9 either, but I was trying to work "within the
system", not subvert it ;-)

Some important questions to ask, I suppose, are how often is SFDIR different
than the current directory for people who are using the commandline ?  Would
it be better for some of the opcodes that I mentioned to write their output
files to the orchestra or score directory instead of SFDIR?  Finally, it
would be good to keep the number of different methods for locating files to
a minimum.  In this spirit, would it be better to make small changes in
behavior to the opcodes that I mentioned (like using SFDIR) instead of
introducing new "compatible" behaviors (the proposed HOSTOUTDIR).

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