I neglected to mention perhaps the most important fact of all: with SoaS, 
any MIDI controller(s) must be plugged in AFTER boot and BEFORE compiling a 
.csnd. Users must be given explicit instruction to this effect.

Note that this limitation does not apply to the XO.

My thoughts are:
1) Getting around this limitation is far more trouble that it's worth;
2) In the world of XO and Sugar-on-a-Stick a potential misunderstanding 
would arise rarely in any case.

Art Hunkins

----- Original Message ----- 
From: "Art Hunkins" 
To: 
Cc: 
Sent: Monday, September 28, 2009 4:35 PM
Subject: Re: [Csnd] Re: Re: Re: Getting around a (sound) device assignment 
problem in SoaS


> Hi, Andres,
>
> With further experimentation, I've found that the following  
> will work fine for my purposes in the XO-1/Sugar-on-a-Stick context:
> -odac -+rtaudio=alsa -+rtmidi=alsa -M hw:1,0
>
> Comments:
>  Alsa is low-latency as is supported (to this date) on all XO and SoaS 
> platforms.
>  -odac refers indeed to the default plughw and makes the conversions you 
> mention, at no apparent cost - whereas -odac:hw:0,0 does not. -odac will 
> thus work as long as there is a single (usually the builtin) hardware 
> device. This is something I can count on.
>  -M hw:1,0 will work as long as only one controller is attached (which I 
> can count on for my single-controller .csd's), and as long as any built-in 
> MIDI interface (rare these days, as Peter pointed out) is not being used. 
> I think I can count on MIDI being via USB. (If someone on the outside 
> chance *did* want to use a builtin MIDI interface, he can change hw:1,0 to 
> hw:0,0.)
>
> So, the above will work in all usual configurations, as long as:
> built-in audio is used;
> one USB MIDI controller is used
>
> For my multiple MIDI controller versions, these will 
> use: -+rtmidi=alsa -Ma
> as soon as Peter finds the time to incorporate your multi-controller 
> patch.
>
> Once this is achieved, all my issues are settled, and I'll be a "happy 
> camper" (= find my joy).
>
> Art Hunkins
>
> ----- Original Message ----- 
> From: "Andres Cabrera" 
> To: 
> Sent: Monday, September 28, 2009 3:27 PM
> Subject: [Csnd] Re: Re: Re: Getting around a (sound) device assignment 
> problem in SoaS
>
>
> Hi,
>
> Since there's been no reply, I'll take a stab, but I may be compeltely 
> wrong...
>
> I think alsa names hw: real hardware devices. Hardware devices can be
> constrained as to the number of channels or sample rates supported.
> There might be software interfaces to these devices (like the alsa
> "default" interface), which are plughw: devices, which can take care
> of sample rate conversion and different number of channels. To
> override the default settings, you would need to mess with the
> .asounrc file, which I wouldn't recommend since it might take you a
> while, as it is not very documented.
>
> Cheers,
> Andres
>
> On Wed, Sep 23, 2009 at 9:41 PM, Art Hunkins  wrote:
>> In starting down the road Victor suggests (and to solve the problem
>> addressed in the subject), I immediately ran into an anomaly. I've no 
>> idea
>> whether the issue is Csound's or Sugar/Linux.
>>
>> Description:
>> In working with the XO-1, I settled on a stereo SR=32000. (This is the
>> maximum SR I can use with my .csd's and get glitch-free sound on the 
>> XO-1.)
>>
>> I developed all my work using the  -odac
>>
>> Faced with the fact of different device assignments with Sugar on a Stick
>> (Soas) when MIDI controller(s) are inserted prior to boot, I need to 
>> check
>> for other assignments for -odac, such as hw:1,0.
>>
>> Bottom line: -odac executed fine with SR=32000; -odac:hw:0,0 (its 
>> apparent
>> equivalent) does not, *though it does fine with SR=44100!* The error 
>> message
>> is: Unable to set sample rate on soundcard. Failed to initialize real 
>> time
>> audio output.
>>
>> Apparently there is a difference between 'plughw' (as -odac is referred 
>> to
>> in my error log) and -odac:hw:0,0 (referred to as hw:0,0 in log).
>>
>> Linux folk: what is going on here? I need both to: 1) use SR=32000, and 
>> 2)
>> test for different hardware device assignments - including -odac:hw:1,0 
>> (it
>> too doesn't like SR=32000).
>>
>> Art Hunkins
>>
>> ----- Original Message ----- From: "victor" 
>> To: 
>> Sent: Tuesday, September 22, 2009 3:52 AM
>> Subject: [Csnd] Re: Getting around a (sound) device assignment problem in
>> SoaS
>>
>>
>>> The compile() function in the API (and in the csndsugui module) returns
>>> 0 if successful and non-zero if not. You can check for this and 
>>> recompile
>>> with different options (etc) until it works.
>>>
>>> Victor
>>>
>>>
>>> ----- Original Message ----- From: "Art Hunkins" 
>>> To: 
>>> Cc: 
>>> Sent: Tuesday, September 22, 2009 4:03 AM
>>> Subject: [Csnd] Getting around a (sound) device assignment problem in 
>>> SoaS
>>>
>>>
>>>> For SoaS (Fedora Linux), there remains a problem of device assignment
>>>> involving audio out and MIDI in.
>>>>
>>>> Basically, if you boot SoaS *then* plug in a MIDI controller, audio is
>>>> assigned C0D0; and MIDI, C1D0 (this is as expected). If you plug in a
>>>> MIDI
>>>> controller and then boot SoaS, MIDI gets C0D0 and audio C1D0 (this is
>>>> *not*
>>>> as expected!)
>>>>
>>>> The latter arrangement generates the following error message (in its 
>>>> Log)
>>>> when
>>>> a script is run:
>>>> Can't open device 'plughw' for audio output.
>>>>
>>>> It will be necessary to either do something either in Sugar, its Csound
>>>> module, or in the python script that runs Csound to work with this 
>>>> issue.
>>>> So far, I've tried making manual changes to the file names (reflecting
>>>> the "proper"
>>>> device numbers, but the error remains.
>>>>
>>>> Suggestions? Especially from the Sugar side?
>>>>
>>>> It would seem that Sugar needs to
>>>> look for and assign *audio* device numbers before *MIDI* device 
>>>> numbers.
>>>> (Please
>>>> note that this issue does *not* exist for the native XO-1. Perhaps
>>>> snooping around
>>>> in that code would be enlightening.) I'd appreciate the help; I'm
>>>> absolutely lost here.
>>>>
>>>> Art Hunkins
>>>>
>>>>
>>>>
>>>> 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"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> -- 
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"= 

Art,

Now that you have figured all this out,  it would be cool for you to  
create a SOS page for us at cSounds.com  or Sourceforge.  What do you  
think.  Victor showed me SOS a few months back and it was pretty  
wonderful.  I think that many csounders would like it especially if  
all the pieces, links, tips and toots were all in one place.

Appreciating all your efforts in this area.

-Rick

Sent from my iPhone

On Sep 29, 2009, at 10:25 AM, "Art Hunkins"  wrote:

> I neglected to mention perhaps the most important fact of all: with  
> SoaS, any MIDI controller(s) must be plugged in AFTER boot and  
> BEFORE compiling a .csnd. Users must be given explicit instruction  
> to this effect.
>
> Note that this limitation does not apply to the XO.
>
> My thoughts are:
> 1) Getting around this limitation is far more trouble that it's worth;
> 2) In the world of XO and Sugar-on-a-Stick a potential  
> misunderstanding would arise rarely in any case.
>
> Art Hunkins
>
> ----- Original Message ----- From: "Art Hunkins" 
> To: 
> Cc: 
> Sent: Monday, September 28, 2009 4:35 PM
> Subject: Re: [Csnd] Re: Re: Re: Getting around a (sound) device  
> assignment problem in SoaS
>
>
>> Hi, Andres,
>>
>> With further experimentation, I've found that the following  
>>  will work fine for my purposes in the XO-1/Sugar-on-a- 
>> Stick context:
>> -odac -+rtaudio=alsa -+rtmidi=alsa -M hw:1,0
>>
>> Comments:
>> Alsa is low-latency as is supported (to this date) on all XO and  
>> SoaS platforms.
>> -odac refers indeed to the default plughw and makes the conversions  
>> you mention, at no apparent cost - whereas -odac:hw:0,0 does not. - 
>> odac will thus work as long as there is a single (usually the  
>> builtin) hardware device. This is something I can count on.
>> -M hw:1,0 will work as long as only one controller is attached  
>> (which I can count on for my single-controller .csd's), and as long  
>> as any built-in MIDI interface (rare these days, as Peter pointed  
>> out) is not being used. I think I can count on MIDI being via USB.  
>> (If someone on the outside chance *did* want to use a builtin MIDI  
>> interface, he can change hw:1,0 to hw:0,0.)
>>
>> So, the above will work in all usual configurations, as long as:
>> built-in audio is used;
>> one USB MIDI controller is used
>>
>> For my multiple MIDI controller versions, these will use: - 
>> +rtmidi=alsa -Ma
>> as soon as Peter finds the time to incorporate your multi- 
>> controller patch.
>>
>> Once this is achieved, all my issues are settled, and I'll be a  
>> "happy camper" (= find my joy).
>>
>> Art Hunkins
>>
>> ----- Original Message ----- From: "Andres Cabrera" > >
>> To: 
>> Sent: Monday, September 28, 2009 3:27 PM
>> Subject: [Csnd] Re: Re: Re: Getting around a (sound) device  
>> assignment problem in SoaS
>>
>>
>> Hi,
>>
>> Since there's been no reply, I'll take a stab, but I may be  
>> compeltely wrong...
>>
>> I think alsa names hw: real hardware devices. Hardware devices can be
>> constrained as to the number of channels or sample rates supported.
>> There might be software interfaces to these devices (like the alsa
>> "default" interface), which are plughw: devices, which can take care
>> of sample rate conversion and different number of channels. To
>> override the default settings, you would need to mess with the
>> .asounrc file, which I wouldn't recommend since it might take you a
>> while, as it is not very documented.
>>
>> Cheers,
>> Andres
>>
>> On Wed, Sep 23, 2009 at 9:41 PM, Art Hunkins   
>> wrote:
>>> In starting down the road Victor suggests (and to solve the problem
>>> addressed in the subject), I immediately ran into an anomaly. I've  
>>> no idea
>>> whether the issue is Csound's or Sugar/Linux.
>>>
>>> Description:
>>> In working with the XO-1, I settled on a stereo SR=32000. (This is  
>>> the
>>> maximum SR I can use with my .csd's and get glitch-free sound on  
>>> the XO-1.)
>>>
>>> I developed all my work using the  -odac
>>>
>>> Faced with the fact of different device assignments with Sugar on  
>>> a Stick
>>> (Soas) when MIDI controller(s) are inserted prior to boot, I need  
>>> to check
>>> for other assignments for -odac, such as hw:1,0.
>>>
>>> Bottom line: -odac executed fine with SR=32000; -odac:hw:0,0 (its  
>>> apparent
>>> equivalent) does not, *though it does fine with SR=44100!* The  
>>> error message
>>> is: Unable to set sample rate on soundcard. Failed to initialize  
>>> real time
>>> audio output.
>>>
>>> Apparently there is a difference between 'plughw' (as -odac is  
>>> referred to
>>> in my error log) and -odac:hw:0,0 (referred to as hw:0,0 in log).
>>>
>>> Linux folk: what is going on here? I need both to: 1) use  
>>> SR=32000, and 2)
>>> test for different hardware device assignments - including - 
>>> odac:hw:1,0 (it
>>> too doesn't like SR=32000).
>>>
>>> Art Hunkins
>>>
>>> ----- Original Message ----- From: "victor" >> >
>>> To: 
>>> Sent: Tuesday, September 22, 2009 3:52 AM
>>> Subject: [Csnd] Re: Getting around a (sound) device assignment  
>>> problem in
>>> SoaS
>>>
>>>
>>>> The compile() function in the API (and in the csndsugui module)  
>>>> returns
>>>> 0 if successful and non-zero if not. You can check for this and  
>>>> recompile
>>>> with different options (etc) until it works.
>>>>
>>>> Victor
>>>>
>>>>
>>>> ----- Original Message ----- From: "Art Hunkins"  
>>>> 
>>>> To: 
>>>> Cc: 
>>>> Sent: Tuesday, September 22, 2009 4:03 AM
>>>> Subject: [Csnd] Getting around a (sound) device assignment  
>>>> problem in SoaS
>>>>
>>>>
>>>>> For SoaS (Fedora Linux), there remains a problem of device  
>>>>> assignment
>>>>> involving audio out and MIDI in.
>>>>>
>>>>> Basically, if you boot SoaS *then* plug in a MIDI controller,  
>>>>> audio is
>>>>> assigned C0D0; and MIDI, C1D0 (this is as expected). If you plug  
>>>>> in a
>>>>> MIDI
>>>>> controller and then boot SoaS, MIDI gets C0D0 and audio C1D0  
>>>>> (this is
>>>>> *not*
>>>>> as expected!)
>>>>>
>>>>> The latter arrangement generates the following error message (in  
>>>>> its Log)
>>>>> when
>>>>> a script is run:
>>>>> Can't open device 'plughw' for audio output.
>>>>>
>>>>> It will be necessary to either do something either in Sugar, its  
>>>>> Csound
>>>>> module, or in the python script that runs Csound to work with  
>>>>> this issue.
>>>>> So far, I've tried making manual changes to the file names  
>>>>> (reflecting
>>>>> the "proper"
>>>>> device numbers, but the error remains.
>>>>>
>>>>> Suggestions? Especially from the Sugar side?
>>>>>
>>>>> It would seem that Sugar needs to
>>>>> look for and assign *audio* device numbers before *MIDI* device  
>>>>> numbers.
>>>>> (Please
>>>>> note that this issue does *not* exist for the native XO-1. Perhaps
>>>>> snooping around
>>>>> in that code would be enlightening.) I'd appreciate the help; I'm
>>>>> absolutely lost here.
>>>>>
>>>>> Art Hunkins
>>>>>
>>>>>
>>>>>
>>>>> 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"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> -- 
>>
>>
>> Andrés
>>
>>
>> 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"

I believe a technical wiki at sourceforge is in order.  The mailing
list is good for current discussions, but information like this tends
to get lost or forgotten in the archives.  I recommend using
Mediawiki.

http://www.mediawiki.org/wiki/MediaWiki

Best,
Jake

On Tue, Sep 29, 2009 at 7:32 AM, Dr. Richard Boulanger
 wrote:
> Art,
>
> Now that you have figured all this out,  it would be cool for you to create
> a SOS page for us at cSounds.com  or Sourceforge.  What do you think.
>  Victor showed me SOS a few months back and it was pretty wonderful.  I
> think that many csounders would like it especially if all the pieces, links,
> tips and toots were all in one place.
>
> Appreciating all your efforts in this area.
>
> -Rick
>
> Sent from my iPhone
>
> On Sep 29, 2009, at 10:25 AM, "Art Hunkins"  wrote:
>
>> I neglected to mention perhaps the most important fact of all: with SoaS,
>> any MIDI controller(s) must be plugged in AFTER boot and BEFORE compiling a
>> .csnd. Users must be given explicit instruction to this effect.
>>
>> Note that this limitation does not apply to the XO.
>>
>> My thoughts are:
>> 1) Getting around this limitation is far more trouble that it's worth;
>> 2) In the world of XO and Sugar-on-a-Stick a potential misunderstanding
>> would arise rarely in any case.
>>
>> Art Hunkins
>>
>> ----- Original Message ----- From: "Art Hunkins" 
>> To: 
>> Cc: 
>> Sent: Monday, September 28, 2009 4:35 PM
>> Subject: Re: [Csnd] Re: Re: Re: Getting around a (sound) device assignment
>> problem in SoaS
>>
>>
>>> Hi, Andres,
>>>
>>> With further experimentation, I've found that the following 
>>> will work fine for my purposes in the XO-1/Sugar-on-a-Stick context:
>>> -odac -+rtaudio=alsa -+rtmidi=alsa -M hw:1,0
>>>
>>> Comments:
>>> Alsa is low-latency as is supported (to this date) on all XO and SoaS
>>> platforms.
>>> -odac refers indeed to the default plughw and makes the conversions you
>>> mention, at no apparent cost - whereas -odac:hw:0,0 does not. -odac will
>>> thus work as long as there is a single (usually the builtin) hardware
>>> device. This is something I can count on.
>>> -M hw:1,0 will work as long as only one controller is attached (which I
>>> can count on for my single-controller .csd's), and as long as any built-in
>>> MIDI interface (rare these days, as Peter pointed out) is not being used. I
>>> think I can count on MIDI being via USB. (If someone on the outside chance
>>> *did* want to use a builtin MIDI interface, he can change hw:1,0 to hw:0,0.)
>>>
>>> So, the above will work in all usual configurations, as long as:
>>> built-in audio is used;
>>> one USB MIDI controller is used
>>>
>>> For my multiple MIDI controller versions, these will use: -+rtmidi=alsa
>>> -Ma
>>> as soon as Peter finds the time to incorporate your multi-controller
>>> patch.
>>>
>>> Once this is achieved, all my issues are settled, and I'll be a "happy
>>> camper" (= find my joy).
>>>
>>> Art Hunkins
>>>
>>> ----- Original Message ----- From: "Andres Cabrera"
>>> 
>>> To: 
>>> Sent: Monday, September 28, 2009 3:27 PM
>>> Subject: [Csnd] Re: Re: Re: Getting around a (sound) device assignment
>>> problem in SoaS
>>>
>>>
>>> Hi,
>>>
>>> Since there's been no reply, I'll take a stab, but I may be compeltely
>>> wrong...
>>>
>>> I think alsa names hw: real hardware devices. Hardware devices can be
>>> constrained as to the number of channels or sample rates supported.
>>> There might be software interfaces to these devices (like the alsa
>>> "default" interface), which are plughw: devices, which can take care
>>> of sample rate conversion and different number of channels. To
>>> override the default settings, you would need to mess with the
>>> .asounrc file, which I wouldn't recommend since it might take you a
>>> while, as it is not very documented.
>>>
>>> Cheers,
>>> Andres
>>>
>>> On Wed, Sep 23, 2009 at 9:41 PM, Art Hunkins  wrote:
>>>>
>>>> In starting down the road Victor suggests (and to solve the problem
>>>> addressed in the subject), I immediately ran into an anomaly. I've no
>>>> idea
>>>> whether the issue is Csound's or Sugar/Linux.
>>>>
>>>> Description:
>>>> In working with the XO-1, I settled on a stereo SR=32000. (This is the
>>>> maximum SR I can use with my .csd's and get glitch-free sound on the
>>>> XO-1.)
>>>>
>>>> I developed all my work using the  -odac
>>>>
>>>> Faced with the fact of different device assignments with Sugar on a
>>>> Stick
>>>> (Soas) when MIDI controller(s) are inserted prior to boot, I need to
>>>> check
>>>> for other assignments for -odac, such as hw:1,0.
>>>>
>>>> Bottom line: -odac executed fine with SR=32000; -odac:hw:0,0 (its
>>>> apparent
>>>> equivalent) does not, *though it does fine with SR=44100!* The error
>>>> message
>>>> is: Unable to set sample rate on soundcard. Failed to initialize real
>>>> time
>>>> audio output.
>>>>
>>>> Apparently there is a difference between 'plughw' (as -odac is referred
>>>> to
>>>> in my error log) and -odac:hw:0,0 (referred to as hw:0,0 in log).
>>>>
>>>> Linux folk: what is going on here? I need both to: 1) use SR=32000, and
>>>> 2)
>>>> test for different hardware device assignments - including -odac:hw:1,0
>>>> (it
>>>> too doesn't like SR=32000).
>>>>
>>>> Art Hunkins
>>>>
>>>> ----- Original Message ----- From: "victor" 
>>>> To: 
>>>> Sent: Tuesday, September 22, 2009 3:52 AM
>>>> Subject: [Csnd] Re: Getting around a (sound) device assignment problem
>>>> in
>>>> SoaS
>>>>
>>>>
>>>>> The compile() function in the API (and in the csndsugui module) returns
>>>>> 0 if successful and non-zero if not. You can check for this and
>>>>> recompile
>>>>> with different options (etc) until it works.
>>>>>
>>>>> Victor
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "Art Hunkins" 
>>>>> To: 
>>>>> Cc: 
>>>>> Sent: Tuesday, September 22, 2009 4:03 AM
>>>>> Subject: [Csnd] Getting around a (sound) device assignment problem in
>>>>> SoaS
>>>>>
>>>>>
>>>>>> For SoaS (Fedora Linux), there remains a problem of device assignment
>>>>>> involving audio out and MIDI in.
>>>>>>
>>>>>> Basically, if you boot SoaS *then* plug in a MIDI controller, audio is
>>>>>> assigned C0D0; and MIDI, C1D0 (this is as expected). If you plug in a
>>>>>> MIDI
>>>>>> controller and then boot SoaS, MIDI gets C0D0 and audio C1D0 (this is
>>>>>> *not*
>>>>>> as expected!)
>>>>>>
>>>>>> The latter arrangement generates the following error message (in its
>>>>>> Log)
>>>>>> when
>>>>>> a script is run:
>>>>>> Can't open device 'plughw' for audio output.
>>>>>>
>>>>>> It will be necessary to either do something either in Sugar, its
>>>>>> Csound
>>>>>> module, or in the python script that runs Csound to work with this
>>>>>> issue.
>>>>>> So far, I've tried making manual changes to the file names (reflecting
>>>>>> the "proper"
>>>>>> device numbers, but the error remains.
>>>>>>
>>>>>> Suggestions? Especially from the Sugar side?
>>>>>>
>>>>>> It would seem that Sugar needs to
>>>>>> look for and assign *audio* device numbers before *MIDI* device
>>>>>> numbers.
>>>>>> (Please
>>>>>> note that this issue does *not* exist for the native XO-1. Perhaps
>>>>>> snooping around
>>>>>> in that code would be enlightening.) I'd appreciate the help; I'm
>>>>>> absolutely lost here.
>>>>>>
>>>>>> Art Hunkins
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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"
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> 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"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"