-1 (as you might guess).

My  are set up for the "average" system and the "average" 
requirements of my realtime compositions.

I'd like my settings to permit most performers to play my pieces "out of the 
box". (Actually, the "enhanced"  would help considerably in this 
regard.)

One crucial  element for me is -M0 or not (or the Linux 
equivalent). In many cases, if -M0 is not there, the performer is unlikely 
to know what went wrong.

Some performers will need to edit (for their hardware, as you say); they'd 
have to edit .csoundrc as well.

Perhaps you are suggesting "none of the above"? I, for one, would like to 
give my performers a fighting chance, and simplify their struggle (and it 
*will* be one for non-Csounders) as much as I can.

Art Hunkins

----- Original Message ----- 
From: "Richard Dobson" 
To: 
Sent: Tuesday, August 18, 2009 3:02 PM
Subject: [Csnd] Re: Re: Re: Re: csoptions idea...


>I am one of those (perhaps a minority) who thought CsOptions was a bad idea 
>from the get-go. The csd  file (a) has no business telling me what hardware 
>to use and how, and (b) there is no way it can work reliably all the time 
>on N unknown hosts. My audio hardware is not even fixed (apart from the mac 
>internal audio which I only use as Plan B or C); they are mostly external 
>Firewire or USB devices, but not quite enough to go around all the machines 
>I have to deal with; so I move them around a lot.
>
> Any time I have cause to play someone's csd file, I have learned simply to 
> delete all the CsOptions; almost invariably whatever -b -B settings it 
> has, don't work. It is for the user to set up the options that work for 
> them, on ~their~ machine; Csound should not dictate that, and most 
> definitely a csd file should not.
>
> Richard Dobson
>
>
>
> Art Hunkins wrote:
>> Steven,
>>
>> Yes.
>>
>> I am not a Blue user, and I write realtime compositions that I hope 
>> others will perform using just my .csd (or Lettuce .exe) and Csound (even 
>> a "stripped down" version, which I supply in a download .zip).
>>
>> I do not know what kind of system the user will have. Right now if 
>> necessary the user edits  (under my instructions); or, in 
>> Lettuce, the performer has direct access to , also editing.
>>
>> BTW, I use no .csoundrc - overriding anything necessary in .csoptions. In 
>> my "stripped down" Csound there are no environment variables either; 
>> everything is run from a single directory.
>>
>
>
>
> 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"

One problem that I myself have with Csound configuration is that I do
not, by any means, always render to the same output. Sometimes I
render to soundfiles, sometimes I render real-time audio. Sometimes I
render a high-resolution soundfile, sometimes I render a preview
soundfile.

Neither .csoundrc nor CsOptions is good for this. What I end up doing
is writing my pieces as scripts which accept a command-line option for
the target, then build an appropriate command line. There is logic in
the scripts to determine what platform the script is running on and
build the right command line for that platform.

This of course is still specialized for my own sound card, MIDI
interface, etc. so it is not a universal solution.

What do others do for multiple output targets?

Regards,
Mike

On 8/18/09, Art Hunkins  wrote:
> -1 (as you might guess).
>
> My  are set up for the "average" system and the "average"
> requirements of my realtime compositions.
>
> I'd like my settings to permit most performers to play my pieces "out of the
> box". (Actually, the "enhanced"  would help considerably in this
> regard.)
>
> One crucial  element for me is -M0 or not (or the Linux
> equivalent). In many cases, if -M0 is not there, the performer is unlikely
> to know what went wrong.
>
> Some performers will need to edit (for their hardware, as you say); they'd
> have to edit .csoundrc as well.
>
> Perhaps you are suggesting "none of the above"? I, for one, would like to
> give my performers a fighting chance, and simplify their struggle (and it
> *will* be one for non-Csounders) as much as I can.
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Richard Dobson" 
> To: 
> Sent: Tuesday, August 18, 2009 3:02 PM
> Subject: [Csnd] Re: Re: Re: Re: csoptions idea...
>
>
>>I am one of those (perhaps a minority) who thought CsOptions was a bad idea
>>
>>from the get-go. The csd  file (a) has no business telling me what hardware
>>
>>to use and how, and (b) there is no way it can work reliably all the time
>>on N unknown hosts. My audio hardware is not even fixed (apart from the mac
>>
>>internal audio which I only use as Plan B or C); they are mostly external
>>Firewire or USB devices, but not quite enough to go around all the machines
>>
>>I have to deal with; so I move them around a lot.
>>
>> Any time I have cause to play someone's csd file, I have learned simply to
>>
>> delete all the CsOptions; almost invariably whatever -b -B settings it
>> has, don't work. It is for the user to set up the options that work for
>> them, on ~their~ machine; Csound should not dictate that, and most
>> definitely a csd file should not.
>>
>> Richard Dobson
>>
>>
>>
>> Art Hunkins wrote:
>>> Steven,
>>>
>>> Yes.
>>>
>>> I am not a Blue user, and I write realtime compositions that I hope
>>> others will perform using just my .csd (or Lettuce .exe) and Csound (even
>>>
>>> a "stripped down" version, which I supply in a download .zip).
>>>
>>> I do not know what kind of system the user will have. Right now if
>>> necessary the user edits  (under my instructions); or, in
>>> Lettuce, the performer has direct access to , also editing.
>>>
>>> BTW, I use no .csoundrc - overriding anything necessary in .csoptions. In
>>>
>>> my "stripped down" Csound there are no environment variables either;
>>> everything is run from a single directory.
>>>
>>
>>
>>
>> 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"
>

Art Hunkins wrote:
> -1 (as you might guess).
> 
> My  are set up for the "average" system and the "average" 
> requirements of my realtime compositions.
> 

What's an "average" system?

> 
> One crucial  element for me is -M0 or not (or the Linux 
> equivalent). In many cases, if -M0 is not there, the performer is 
> unlikely to know what went wrong.
> 

In my case this is moot; most of the time I have no Midi device plugged 
in (USB again...), and at other times I have two - and will then 
typically be using the second device, not the first.

> Some performers will need to edit (for their hardware, as you say); 
> they'd have to edit .csoundrc as well.
> 

If users have to edit that every time, how is that less tiresome than 
editing CsOptions? The whole idea (I ~thought~) of .csoundrc was to 
setup the standard options for ~your~ csound on ~your~ machine, once and 
once only, to be changed hardly ever. Someone like me with hardware that 
is decidedly variable might accept the need to edit it, but on the 
putative "average" machine it would presumably only need to be done once 
- this audio device, that Midi device, these buffer settings, and so on.

The thing is - speaking in terms of the user of an average machine - I 
have just one of those, but I might want to play 1001 csds from around 
the planet, each of which is electing to configure my setup in a 
different way!

To put it another way - as described here:
http://www.csounds.com/manual/html/CommandTop.html#CommandOrder

IMO the order is back to front - CsOptions (assuming losing that is not 
an option) and .csoundrc should be swapped in order.

I suppose what I/we really need is a single csound flag option to choose 
either .csoundrc or the CsOptions (or even more simply - to ignore 
CsOptions). I would put that in my .csoundrc and be a happy bunny!


Richard Dobson




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

Hi Richard,

You can use -+ignore_csopts=true in .csoundrc which will make csound
ignore CsOptions.

Cheers!
steven

On Tue, Aug 18, 2009 at 3:59 PM, Richard
Dobson wrote:
> Art Hunkins wrote:
>>
>> -1 (as you might guess).
>>
>> My  are set up for the "average" system and the "average"
>> requirements of my realtime compositions.
>>
>
> What's an "average" system?
>
>>
>> One crucial  element for me is -M0 or not (or the Linux
>> equivalent). In many cases, if -M0 is not there, the performer is unlikely
>> to know what went wrong.
>>
>
> In my case this is moot; most of the time I have no Midi device plugged in
> (USB again...), and at other times I have two - and will then typically be
> using the second device, not the first.
>
>> Some performers will need to edit (for their hardware, as you say); they'd
>> have to edit .csoundrc as well.
>>
>
> If users have to edit that every time, how is that less tiresome than
> editing CsOptions? The whole idea (I ~thought~) of .csoundrc was to setup
> the standard options for ~your~ csound on ~your~ machine, once and once
> only, to be changed hardly ever. Someone like me with hardware that is
> decidedly variable might accept the need to edit it, but on the putative
> "average" machine it would presumably only need to be done once - this audio
> device, that Midi device, these buffer settings, and so on.
>
> The thing is - speaking in terms of the user of an average machine - I have
> just one of those, but I might want to play 1001 csds from around the
> planet, each of which is electing to configure my setup in a different way!
>
> To put it another way - as described here:
> http://www.csounds.com/manual/html/CommandTop.html#CommandOrder
>
> IMO the order is back to front - CsOptions (assuming losing that is not an
> option) and .csoundrc should be swapped in order.
>
> I suppose what I/we really need is a single csound flag option to choose
> either .csoundrc or the CsOptions (or even more simply - to ignore
> CsOptions). I would put that in my .csoundrc and be a happy bunny!
>
>
> Richard Dobson
>
>
>
>
> 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"

Steven Yi wrote:
> Hi Richard,
> 
> You can use -+ignore_csopts=true in .csoundrc which will make csound
> ignore CsOptions.
> 
  Great, thanks, useful to know. Still think CsOptions is a bad idea though!

Richard Dobson



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