joachim heintz wrote on Sep 10, 2009 10:44am:

> I see two different behaviours of Csound in treating relative pathnames.
> When I use 
> #include "../MyUdos.txt"
> the dots are interpreted relative to the path of the .csd (and the  
> file is searched in the top directory). This was what I expected.
> But when I use 
> ftsave "../MyFt.ftsave" or
> fout "../MySound.wav"
> the dots are interpreted relative to the directory of the binary (if I  
> use QuteCsound) or the working directory (if I use the terminal).
> Why? 
> Is there a way to use relative pathnames in ftsave or fout relative to  
> the path of the .csd, too?
> Thanks - 

Well, I notice that your examples are doing two different things.  #include
is reading a file while ftsave and fout are writing files.  Csound has a
different defined order for determining where these operations take place in
the file system.  To a certain extent, this makes sense because when reading
a file, Csound searchs for that file in multiple locations and uses the
first matching file that it finds.  When writing a file, no searching is
necessary (or desired): the write directory must be a single destination.

Now as to the logic of where files get written, I had invested a lot of time
into suggesting changes to Csound that would make it work more sensibly in
this new age of the proliferation of Csound front ends using the API.
Basically, I wanted front ends to be able to set a "working directory" via
the API so that the highly undesirable problem of new files being written to
the directory of the front end would not happen.  It would be up to the
particular front end then to decide what made sense or to give the user a
choice.  Presumably, writing to the CSD directory would be a popular option.
Unfortunately, there was significant resistance to my proposals, so I gave
up for a while.

However, I think there is already a way that you can get around this issue,
at least partially.  Try defining the SFDIR environment variable --
QuteCsound may allow you to do this in its options pane.  I believe that
will force fout at a minimum to write to the location you specify.  I'm not
sure that ftsave will pay attention to SFDIR though.  (I tried to change the
behavior of ftsave or dumpf too but got shot down).

Good luck!

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

P.S.  Note that I do not receive messages from this list, so please include
me in your reply if you want me to respond.  Thanks.



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks a lot, Anthony, for your thoroughly clarification.
And nice to hear from you at all.
Best regards -
	joachim


Am 18.09.2009 um 18:57 schrieb Anthony Kozar:

> joachim heintz wrote on Sep 10, 2009 10:44am:
>
>> I see two different behaviours of Csound in treating relative  
>> pathnames.
>> When I use
>> #include "../MyUdos.txt"
>> the dots are interpreted relative to the path of the .csd (and the
>> file is searched in the top directory). This was what I expected.
>> But when I use
>> ftsave "../MyFt.ftsave" or
>> fout "../MySound.wav"
>> the dots are interpreted relative to the directory of the binary  
>> (if I
>> use QuteCsound) or the working directory (if I use the terminal).
>> Why?
>> Is there a way to use relative pathnames in ftsave or fout relative  
>> to
>> the path of the .csd, too?
>> Thanks -
>
> Well, I notice that your examples are doing two different things.   
> #include
> is reading a file while ftsave and fout are writing files.  Csound  
> has a
> different defined order for determining where these operations take  
> place in
> the file system.  To a certain extent, this makes sense because when  
> reading
> a file, Csound searchs for that file in multiple locations and uses  
> the
> first matching file that it finds.  When writing a file, no  
> searching is
> necessary (or desired): the write directory must be a single  
> destination.
>
> Now as to the logic of where files get written, I had invested a lot  
> of time
> into suggesting changes to Csound that would make it work more  
> sensibly in
> this new age of the proliferation of Csound front ends using the API.
> Basically, I wanted front ends to be able to set a "working  
> directory" via
> the API so that the highly undesirable problem of new files being  
> written to
> the directory of the front end would not happen.  It would be up to  
> the
> particular front end then to decide what made sense or to give the  
> user a
> choice.  Presumably, writing to the CSD directory would be a popular  
> option.
> Unfortunately, there was significant resistance to my proposals, so  
> I gave
> up for a while.
>
> However, I think there is already a way that you can get around this  
> issue,
> at least partially.  Try defining the SFDIR environment variable --
> QuteCsound may allow you to do this in its options pane.  I believe  
> that
> will force fout at a minimum to write to the location you specify.   
> I'm not
> sure that ftsave will pay attention to SFDIR though.  (I tried to  
> change the
> behavior of ftsave or dumpf too but got shot down).
>
> Good luck!
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
> P.S.  Note that I do not receive messages from this list, so please  
> include
> me in your reply if you want me to respond.  Thanks.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"