Hi All,

I'm trying to solve a problem reported by a Blue user about the fout
opcode.  In Blue, when I use the commandline Csound and create a new
process to run, I have the new process start in the directory that
contains the generated CSD (which is also the same as the .blue
project).  This means if a user uses:

fout "somefile.wav", 0, asig

it will be written to the same directory as the .blue and .csd files.

However, when using the API, I've got a problem. Java doesn't support
changing the current working directory[1] for the application.
Running the project ends up trying to write files relative to the
application's current directory, which may not be writable.

Question: Anyone have suggestions for this scenario?  What happens in
Cabbage and CsoundQt?  Should I maybe set SFDIR when running Csound?

Thanks!
steven

[1] - http://www.devx.com/tips/Tip/13804

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I've noticed some strangeness around this too, although it was only
ever reported as an issue when using the Python opcodes. Changing the
working directory somehow didn't seem to work the Python opcodes. As a
simple fix for now, users can query a reserved channel called
"CSD_PATH" to retrieve the current path, pass it to a string, and away
they go. It did the trick for Oeyvind and his Python/Cabbage projects.

On 7 April 2014 16:45, Steven Yi  wrote:
> Hi All,
>
> I'm trying to solve a problem reported by a Blue user about the fout
> opcode.  In Blue, when I use the commandline Csound and create a new
> process to run, I have the new process start in the directory that
> contains the generated CSD (which is also the same as the .blue
> project).  This means if a user uses:
>
> fout "somefile.wav", 0, asig
>
> it will be written to the same directory as the .blue and .csd files.
>
> However, when using the API, I've got a problem. Java doesn't support
> changing the current working directory[1] for the application.
> Running the project ends up trying to write files relative to the
> application's current directory, which may not be writable.
>
> Question: Anyone have suggestions for this scenario?  What happens in
> Cabbage and CsoundQt?  Should I maybe set SFDIR when running Csound?
>
> Thanks!
> steven
>
> [1] - http://www.devx.com/tips/Tip/13804
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, and this workaround works nice. I seem to remember some issue
(earlier) where Cabbage would also have problems locating sound files
to be loaded, using a path relative to the csd.
This all works fine in Cabbbage now. Still I wonder if it would
perhaps be even better to enable a solution where Csound itself could
tackle the working directory problem. With the current situation, a
csd will render differently under different frontends, and as been
shown earlier, the same front end on different platforms could also
produce different results. With different results I mean locating
external files in this case, and this could simply lead to an error,
or even load another version of a file with the same name. I know that
solving the cwd problem is not straightforward, especially finding a
crossplatform solution that will "just work".
Just an idea, Csound needs to know where the CSD is to be able to load
it in the first place. Would it be possible to set the csd path as the
working directory for Csound itself? So, even if Csound is running
inside another host/environment/... it will keep track of its own path
and use that internally for file input and output. I'm aware that it
might be a naive assumption that this would actually work, but could
be worth a try ?


2014-04-07 22:18 GMT+02:00 Rory Walsh :
> I've noticed some strangeness around this too, although it was only
> ever reported as an issue when using the Python opcodes. Changing the
> working directory somehow didn't seem to work the Python opcodes. As a
> simple fix for now, users can query a reserved channel called
> "CSD_PATH" to retrieve the current path, pass it to a string, and away
> they go. It did the trick for Oeyvind and his Python/Cabbage projects.
>
> On 7 April 2014 16:45, Steven Yi  wrote:
>> Hi All,
>>
>> I'm trying to solve a problem reported by a Blue user about the fout
>> opcode.  In Blue, when I use the commandline Csound and create a new
>> process to run, I have the new process start in the directory that
>> contains the generated CSD (which is also the same as the .blue
>> project).  This means if a user uses:
>>
>> fout "somefile.wav", 0, asig
>>
>> it will be written to the same directory as the .blue and .csd files.
>>
>> However, when using the API, I've got a problem. Java doesn't support
>> changing the current working directory[1] for the application.
>> Running the project ends up trying to write files relative to the
>> application's current directory, which may not be writable.
>>
>> Question: Anyone have suggestions for this scenario?  What happens in
>> Cabbage and CsoundQt?  Should I maybe set SFDIR when running Csound?
>>
>> Thanks!
>> steven
>>
>> [1] - http://www.devx.com/tips/Tip/13804
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, there are a couple of problems here:

* There might not even be a CSD to reference, so we need a solution for this.

* If you do "csound /path/to/some/file.csd  -o test.wav" that
currently places the file in the current directory. If you do that and
it uses fout, it will also go into the current directory.

An API application can easily handle the -o scenario to control
wherever the global output should be written to.

I just did a test and using:

csound --env:SFDIR="/Users/stevenyi" fout-test.csd

Wrote the output of fout to my home directory, rather than in the
directory of the CSD.

I think then what I will do is this:

* Set SFDIR when running a CSD to the directory where the CSD is located.

* If there is no CSD, I will default to current working directory, or
set SFDIR depending on the needs of the application (not a scenario
used in Blue really)

I think then that this should solve my immediate problem. If I run it
with -o test.wav and set the SFDIR, it will write the file to the
SFDIR. This might be a good practice in general to use from an API
application.



On Tue, Apr 8, 2014 at 3:09 AM, Oeyvind Brandtsegg
 wrote:
> Yes, and this workaround works nice. I seem to remember some issue
> (earlier) where Cabbage would also have problems locating sound files
> to be loaded, using a path relative to the csd.
> This all works fine in Cabbbage now. Still I wonder if it would
> perhaps be even better to enable a solution where Csound itself could
> tackle the working directory problem. With the current situation, a
> csd will render differently under different frontends, and as been
> shown earlier, the same front end on different platforms could also
> produce different results. With different results I mean locating
> external files in this case, and this could simply lead to an error,
> or even load another version of a file with the same name. I know that
> solving the cwd problem is not straightforward, especially finding a
> crossplatform solution that will "just work".
> Just an idea, Csound needs to know where the CSD is to be able to load
> it in the first place. Would it be possible to set the csd path as the
> working directory for Csound itself? So, even if Csound is running
> inside another host/environment/... it will keep track of its own path
> and use that internally for file input and output. I'm aware that it
> might be a naive assumption that this would actually work, but could
> be worth a try ?
>
>
> 2014-04-07 22:18 GMT+02:00 Rory Walsh :
>> I've noticed some strangeness around this too, although it was only
>> ever reported as an issue when using the Python opcodes. Changing the
>> working directory somehow didn't seem to work the Python opcodes. As a
>> simple fix for now, users can query a reserved channel called
>> "CSD_PATH" to retrieve the current path, pass it to a string, and away
>> they go. It did the trick for Oeyvind and his Python/Cabbage projects.
>>
>> On 7 April 2014 16:45, Steven Yi  wrote:
>>> Hi All,
>>>
>>> I'm trying to solve a problem reported by a Blue user about the fout
>>> opcode.  In Blue, when I use the commandline Csound and create a new
>>> process to run, I have the new process start in the directory that
>>> contains the generated CSD (which is also the same as the .blue
>>> project).  This means if a user uses:
>>>
>>> fout "somefile.wav", 0, asig
>>>
>>> it will be written to the same directory as the .blue and .csd files.
>>>
>>> However, when using the API, I've got a problem. Java doesn't support
>>> changing the current working directory[1] for the application.
>>> Running the project ends up trying to write files relative to the
>>> application's current directory, which may not be writable.
>>>
>>> Question: Anyone have suggestions for this scenario?  What happens in
>>> Cabbage and CsoundQt?  Should I maybe set SFDIR when running Csound?
>>>
>>> Thanks!
>>> steven
>>>
>>> [1] - http://www.devx.com/tips/Tip/13804
>>>
>>> ------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees_APR
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sounds like a good idea Steven. I'll look to do the same.

On 8 April 2014 15:19, Steven Yi  wrote:
> Well, there are a couple of problems here:
>
> * There might not even be a CSD to reference, so we need a solution for this.
>
> * If you do "csound /path/to/some/file.csd  -o test.wav" that
> currently places the file in the current directory. If you do that and
> it uses fout, it will also go into the current directory.
>
> An API application can easily handle the -o scenario to control
> wherever the global output should be written to.
>
> I just did a test and using:
>
> csound --env:SFDIR="/Users/stevenyi" fout-test.csd
>
> Wrote the output of fout to my home directory, rather than in the
> directory of the CSD.
>
> I think then what I will do is this:
>
> * Set SFDIR when running a CSD to the directory where the CSD is located.
>
> * If there is no CSD, I will default to current working directory, or
> set SFDIR depending on the needs of the application (not a scenario
> used in Blue really)
>
> I think then that this should solve my immediate problem. If I run it
> with -o test.wav and set the SFDIR, it will write the file to the
> SFDIR. This might be a good practice in general to use from an API
> application.
>
>
>
> On Tue, Apr 8, 2014 at 3:09 AM, Oeyvind Brandtsegg
>  wrote:
>> Yes, and this workaround works nice. I seem to remember some issue
>> (earlier) where Cabbage would also have problems locating sound files
>> to be loaded, using a path relative to the csd.
>> This all works fine in Cabbbage now. Still I wonder if it would
>> perhaps be even better to enable a solution where Csound itself could
>> tackle the working directory problem. With the current situation, a
>> csd will render differently under different frontends, and as been
>> shown earlier, the same front end on different platforms could also
>> produce different results. With different results I mean locating
>> external files in this case, and this could simply lead to an error,
>> or even load another version of a file with the same name. I know that
>> solving the cwd problem is not straightforward, especially finding a
>> crossplatform solution that will "just work".
>> Just an idea, Csound needs to know where the CSD is to be able to load
>> it in the first place. Would it be possible to set the csd path as the
>> working directory for Csound itself? So, even if Csound is running
>> inside another host/environment/... it will keep track of its own path
>> and use that internally for file input and output. I'm aware that it
>> might be a naive assumption that this would actually work, but could
>> be worth a try ?
>>
>>
>> 2014-04-07 22:18 GMT+02:00 Rory Walsh :
>>> I've noticed some strangeness around this too, although it was only
>>> ever reported as an issue when using the Python opcodes. Changing the
>>> working directory somehow didn't seem to work the Python opcodes. As a
>>> simple fix for now, users can query a reserved channel called
>>> "CSD_PATH" to retrieve the current path, pass it to a string, and away
>>> they go. It did the trick for Oeyvind and his Python/Cabbage projects.
>>>
>>> On 7 April 2014 16:45, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> I'm trying to solve a problem reported by a Blue user about the fout
>>>> opcode.  In Blue, when I use the commandline Csound and create a new
>>>> process to run, I have the new process start in the directory that
>>>> contains the generated CSD (which is also the same as the .blue
>>>> project).  This means if a user uses:
>>>>
>>>> fout "somefile.wav", 0, asig
>>>>
>>>> it will be written to the same directory as the .blue and .csd files.
>>>>
>>>> However, when using the API, I've got a problem. Java doesn't support
>>>> changing the current working directory[1] for the application.
>>>> Running the project ends up trying to write files relative to the
>>>> application's current directory, which may not be writable.
>>>>
>>>> Question: Anyone have suggestions for this scenario?  What happens in
>>>> Cabbage and CsoundQt?  Should I maybe set SFDIR when running Csound?
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> [1] - http://www.devx.com/tips/Tip/13804
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Put Bad Developers to Shame
>>>> Dominate Development with Jenkins Continuous Integration
>>>> Continuously Automate Build, Test & Deployment
>>>> Start a new project now. Try Jenkins in the cloud.
>>>> http://p.sf.net/sfu/13600_Cloudbees_APR
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I did some tests and the SFDIR solution seems to be working well for
me at least. I haven't tested with concurrent Csound instances, but it
seems like it should work.

On Tue, Apr 8, 2014 at 2:26 PM, Andres Cabrera  wrote:
> Hi,
>
> Not really useful for you, but I do it using Qt whenver the play button is
> pressed:
>
> QDir::setCurrent(fileName.left(fileName.lastIndexOf('/')));
>
> This changes the application'e current working directory (so it might
> actually be an issue if you are running multiple instances, but no-one has
> complained... :) )
> Maybe I should also be setting SFDIR instead of this?
>
> Cheers,
> Andrés
>
>
>
> On Tue, Apr 8, 2014 at 7:19 AM, Steven Yi  wrote:
>>
>> Well, there are a couple of problems here:
>>
>> * There might not even be a CSD to reference, so we need a solution for
>> this.
>>
>> * If you do "csound /path/to/some/file.csd  -o test.wav" that
>> currently places the file in the current directory. If you do that and
>> it uses fout, it will also go into the current directory.
>>
>> An API application can easily handle the -o scenario to control
>> wherever the global output should be written to.
>>
>> I just did a test and using:
>>
>> csound --env:SFDIR="/Users/stevenyi" fout-test.csd
>>
>> Wrote the output of fout to my home directory, rather than in the
>> directory of the CSD.
>>
>> I think then what I will do is this:
>>
>> * Set SFDIR when running a CSD to the directory where the CSD is located.
>>
>> * If there is no CSD, I will default to current working directory, or
>> set SFDIR depending on the needs of the application (not a scenario
>> used in Blue really)
>>
>> I think then that this should solve my immediate problem. If I run it
>> with -o test.wav and set the SFDIR, it will write the file to the
>> SFDIR. This might be a good practice in general to use from an API
>> application.
>>
>>
>>
>> On Tue, Apr 8, 2014 at 3:09 AM, Oeyvind Brandtsegg
>>  wrote:
>> > Yes, and this workaround works nice. I seem to remember some issue
>> > (earlier) where Cabbage would also have problems locating sound files
>> > to be loaded, using a path relative to the csd.
>> > This all works fine in Cabbbage now. Still I wonder if it would
>> > perhaps be even better to enable a solution where Csound itself could
>> > tackle the working directory problem. With the current situation, a
>> > csd will render differently under different frontends, and as been
>> > shown earlier, the same front end on different platforms could also
>> > produce different results. With different results I mean locating
>> > external files in this case, and this could simply lead to an error,
>> > or even load another version of a file with the same name. I know that
>> > solving the cwd problem is not straightforward, especially finding a
>> > crossplatform solution that will "just work".
>> > Just an idea, Csound needs to know where the CSD is to be able to load
>> > it in the first place. Would it be possible to set the csd path as the
>> > working directory for Csound itself? So, even if Csound is running
>> > inside another host/environment/... it will keep track of its own path
>> > and use that internally for file input and output. I'm aware that it
>> > might be a naive assumption that this would actually work, but could
>> > be worth a try ?
>> >
>> >
>> > 2014-04-07 22:18 GMT+02:00 Rory Walsh :
>> >> I've noticed some strangeness around this too, although it was only
>> >> ever reported as an issue when using the Python opcodes. Changing the
>> >> working directory somehow didn't seem to work the Python opcodes. As a
>> >> simple fix for now, users can query a reserved channel called
>> >> "CSD_PATH" to retrieve the current path, pass it to a string, and away
>> >> they go. It did the trick for Oeyvind and his Python/Cabbage projects.
>> >>
>> >> On 7 April 2014 16:45, Steven Yi  wrote:
>> >>> Hi All,
>> >>>
>> >>> I'm trying to solve a problem reported by a Blue user about the fout
>> >>> opcode.  In Blue, when I use the commandline Csound and create a new
>> >>> process to run, I have the new process start in the directory that
>> >>> contains the generated CSD (which is also the same as the .blue
>> >>> project).  This means if a user uses:
>> >>>
>> >>> fout "somefile.wav", 0, asig
>> >>>
>> >>> it will be written to the same directory as the .blue and .csd files.
>> >>>
>> >>> However, when using the API, I've got a problem. Java doesn't support
>> >>> changing the current working directory[1] for the application.
>> >>> Running the project ends up trying to write files relative to the
>> >>> application's current directory, which may not be writable.
>> >>>
>> >>> Question: Anyone have suggestions for this scenario?  What happens in
>> >>> Cabbage and CsoundQt?  Should I maybe set SFDIR when running Csound?
>> >>>
>> >>> Thanks!
>> >>> steven
>> >>>
>> >>> [1] - http://www.devx.com/tips/Tip/13804
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Put Bad Developers to Shame
>> >>> Dominate Development with Jenkins Continuous Integration
>> >>> Continuously Automate Build, Test & Deployment
>> >>> Start a new project now. Try Jenkins in the cloud.
>> >>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Put Bad Developers to Shame
>> >> Dominate Development with Jenkins Continuous Integration
>> >> Continuously Automate Build, Test & Deployment
>> >> Start a new project now. Try Jenkins in the cloud.
>> >> http://p.sf.net/sfu/13600_Cloudbees
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> > --
>> >
>> > Oeyvind Brandtsegg
>> > Professor of Music Technology
>> > NTNU
>> > 7491 Trondheim
>> > Norway
>> > Cell: +47 92 203 205
>> >
>> > http://flyndresang.no/
>> > http://www.partikkelaudio.com/
>> > http://soundcloud.com/brandtsegg
>> > http://soundcloud.com/t-emp
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Put Bad Developers to Shame
>> > Dominate Development with Jenkins Continuous Integration
>> > Continuously Automate Build, Test & Deployment
>> > Start a new project now. Try Jenkins in the cloud.
>> > http://p.sf.net/sfu/13600_Cloudbees
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net