I have some questions about recent changes in Csound 5.

I noticed that output now goes to stderr instead of stdout on non-Windows
platforms so that "-o stdout" does not get corrupted. This obviously is a
good idea, but should it be this way on Windows also?

I also noticed that option parsing was changed to disallow using .orc and
.sco names in .csd and .csoundrc files.  However, this breaks some behavior
of CsoundVST, which depends on being able to include .orc and .sco
filenames in .csd files. This is because CsoundVST loads and edits .csd
files, but it does not perform them as .csd files; it performs them by
exporting the .orc and .sco file separately. The reason for this is that in
Python mode, CsoundVST generates the .sco file programmatically, using the
name given on the Csound command line, and it also still exports the .orc
file in the usual way.

So I changed the code back to permit .orc and .sco filenames in .csd files.
The .csd files now work both ways -- either with, or without, .orc and .sco
filenames. 

But obviously we need to discuss this. Is there something else that breaks
if .orc and .sco filenames are permitted in .csd files?

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

gogins@pipeline.com wrote:

> I noticed that output now goes to stderr instead of stdout on non-Windows
> platforms so that "-o stdout" does not get corrupted. This obviously is a
> good idea, but should it be this way on Windows also?

I do not really care about whether messages are printed to stderr or stdout
on Windows, so if you prefer stderr, then the check for WIN32 can be removed.
The only reason for printing to stdout was that the DOS/Windows command line
does not allow redirection of stderr, only stdout, and -o stdout is not
available on Win32.

> I also noticed that option parsing was changed to disallow using .orc and
> .sco names in .csd and .csoundrc files.  However, this breaks some behavior
> of CsoundVST, which depends on being able to include .orc and .sco
> filenames in .csd files. This is because CsoundVST loads and edits .csd
> files, but it does not perform them as .csd files; it performs them by
> exporting the .orc and .sco file separately. The reason for this is that in
> Python mode, CsoundVST generates the .sco file programmatically, using the
> name given on the Csound command line, and it also still exports the .orc
> file in the usual way.

So, you want orc and sco names in the CSD. Now, if the CSD contains a CSD
name, should it then be loaded recursively (it may contain a CSD name and
so on) ? What exact behavior do you expect ?

> But obviously we need to discuss this. Is there something else that breaks
> if .orc and .sco filenames are permitted in .csd files?

I will check if the changes introduced any problems.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

gogins@pipeline.com wrote:

>I also noticed that option parsing was changed to disallow using .orc and
>.sco names in .csd and .csoundrc files.  However, this breaks some behavior
>of CsoundVST, which depends on being able to include .orc and .sco
>filenames in .csd files. This is because CsoundVST loads and edits .csd
>files, but it does not perform them as .csd files; it performs them by
>exporting the .orc and .sco file separately. The reason for this is that in
>Python mode, CsoundVST generates the .sco file programmatically, using the
>name given on the Csound command line, and it also still exports the .orc
>file in the usual way.
>  
>
Does this mean that CsoundVST is building again ?

I'll check it out on RH9 asap.

Best,

dp




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It seems like a bad idea to me to use the  in a way which is not
compatible with other versions of Csound.  Perhaps you should take a look at
what Matt has done in MacCsound.  He saves MacCsound-specific options
inbetween  and  tags.

The only reason I can think of to have orchname and scorename in a CSD would
be if there were no  or  tags and those files were
created beforehand, but you still pass the .csd as an argument to Csound.
Is this what you are doing?

Anthony

On 2/20/05 12:29 PM, gogins@pipeline.com  etched in
stone:

> I also noticed that option parsing was changed to disallow using .orc and
> .sco names in .csd and .csoundrc files.  However, this breaks some behavior
> of CsoundVST, which depends on being able to include .orc and .sco
> filenames in .csd files.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net