yes, you are right. At the moment, spin and spout have to have the  
same number of channels (ie. frames of the same size). Possibly  
something to put on the list for the next API increment?

Victor


On 2 Dec 2009, at 22:21, fons@kokkinizita.net wrote:

> Hello all,
>
> Is there any chance of Csound ever allowing a different
> number of input and output channels, in particular when
> used with Jack ? It's somehow absurd to have 64 inputs
> when you only need 2. Or the inverse.
>
> AFAICS, required changes could go rather deep. Not only
> the command line interface doesn't support this, but
> also the CSOUND struct just has 'nchnls' instead of
> two separate values.
>
> Ciao,
>
> -- 
> FA
>
> Wie der Mond heute Nacht aussieht !
> Ist es nicht ein seltsames Bild ?
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The easiest, and probably also the best, way to deal with this is to
write 2 new input and output opcodes, each taking an independent
number of channels, named something like "vin" and "vout".

All asig variables are 1 channel, so there is nothing in between input
and output that needs to be specific for a given number of channels.
The reason the number exists is because of Unix-y assumptions about
piping audio in and out of Csound, and the middle layer of the audio
drivers.

In other words, instead of

aleft, aright ins
outs aleft, aright

You could do this

ain1, ain2 vin 2

Followed by this

vout 4, aout1, aout2, aout3, aout4

For this to work, the new opcodes would have to provide their own
middle layers.

The spout and spin buffers would then simply not be used at all.

I THINK this would work.

Regards,
Mike



On 12/2/09, fons@kokkinizita.net  wrote:
> Hello all,
>
> Is there any chance of Csound ever allowing a different
> number of input and output channels, in particular when
> used with Jack ? It's somehow absurd to have 64 inputs
> when you only need 2. Or the inverse.
>
> AFAICS, required changes could go rather deep. Not only
> the command line interface doesn't support this, but
> also the CSOUND struct just has 'nchnls' instead of
> two separate values.
>
> Ciao,
>
> --
> FA
>
> Wie der Mond heute Nacht aussieht !
> Ist es nicht ein seltsames Bild ?
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I assumed spin and spout would not be used.

MKG from cell phone

On Dec 2, 2009 7:38 PM, <fons@kokkinizita.net> wrote:

On Wed, Dec 02, 2009 at 06:37:39PM -0500, Michael Gogins wrote: > The easiest, and probably also the...

Probably yes, but what is gained w.r.t. the existing inch, inrg,
outch, outrg ? AFAICS these provide the same functionality (with
inch limited to one channel at a time, but that is not a real
problem).

If the spout and spin buffer would still exist in the same form
then probably so will the Jack ports and everything associated
with them. The point of my question (maybe not clearly put) was
if these could be trimmed to just the ones required, removing
some clutter and overhead.

One solution maybe could be to have two new constants (and
command line options) 'ninputs' and 'noutputs', and set nchnls
to the smallest of these if both are nonzero. So nothing would
change if they are equal. Then your new opcodes and/or inch,
inrg, outch, outrg would have a range determined by ninputs resp.
noutputs, while the others would depend on nchnls in the same
way as they do now.

Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ------------...

Is the issue needing 64 jack channels when you only need 2?

In that case, csound does not need to be touched. What we need is a  
jack client with the required number of inputs and outputs and then  
running csound with nchnls = max(in, out). The client would copy just  
the required channels into spin or retrieve only the required channels  
from spout.

The only overhead is a bit more memory in spin or spout than you  
actually need.

Possible and not that difficult to do.

Victor

On 3 Dec 2009, at 00:33, fons@kokkinizita.net wrote:

> On Wed, Dec 02, 2009 at 06:37:39PM -0500, Michael Gogins wrote:
>> The easiest, and probably also the best, way to deal with this is to
>> write 2 new input and output opcodes, each taking an independent
>> number of channels, named something like "vin" and "vout".
>>
>> All asig variables are 1 channel, so there is nothing in between  
>> input
>> and output that needs to be specific for a given number of channels.
>> The reason the number exists is because of Unix-y assumptions about
>> piping audio in and out of Csound, and the middle layer of the audio
>> drivers.
>>
>> In other words, instead of
>>
>> aleft, aright ins
>> outs aleft, aright
>>
>> You could do this
>>
>> ain1, ain2 vin 2
>>
>> Followed by this
>>
>> vout 4, aout1, aout2, aout3, aout4
>>
>> For this to work, the new opcodes would have to provide their own
>> middle layers.
>>
>> The spout and spin buffers would then simply not be used at all.
>>
>> I THINK this would work.
>
> Probably yes, but what is gained w.r.t. the existing inch, inrg,
> outch, outrg ? AFAICS these provide the same functionality (with
> inch limited to one channel at a time, but that is not a real
> problem).
>
> If the spout and spin buffer would still exist in the same form
> then probably so will the Jack ports and everything associated
> with them. The point of my question (maybe not clearly put) was
> if these could be trimmed to just the ones required, removing
> some clutter and overhead.
>
> One solution maybe could be to have two new constants (and
> command line options) 'ninputs' and 'noutputs', and set nchnls
> to the smallest of these if both are nonzero. So nothing would
> change if they are equal. Then your new opcodes and/or inch,
> inrg, outch, outrg would have a range determined by ninputs resp.
> noutputs, while the others would depend on nchnls in the same
> way as they do now.
>
>
> Ciao,
>
> -- 
> FA
>
> Wie der Mond heute Nacht aussieht !
> Ist es nicht ein seltsames Bild ?
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

WOuld it not be simpler for users to separate nchnls into two cases?
An initial attemot would be to use a different name (but mapped to
same variable) and then extend on a case-by-case basis.
==John ffitch

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am not sure I follow you. Can you elaborate?
On 3 Dec 2009, at 09:58, john ffitch wrote:

> WOuld it not be simpler for users to separate nchnls into two cases?
> An initial attemot would be to use a different name (but mapped to
> same variable) and then extend on a case-by-case basis.
> ==John ffitch
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "fons" == fons   writes:

 fons> Hello all,
 fons> Is there any chance of Csound ever allowing a different
 fons> number of input and output channels, in particular when
 fons> used with Jack ? It's somehow absurd to have 64 inputs
 fons> when you only need 2. Or the inverse.

I have been looking into this.  I have a test version that has a new
header statement
       nchns_i = 4
that allocates spin of this size.  Idea is to default to nchns as at
present.  I suspect it might need a API upgrade, but I think I can
accommodate it.  So far I have been separating use, but keeping the
same location via a macro.  Code is committed top CVS so anyone can
correct or criticise.  Depends on how long the marking takes.....

==John ffitch

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Is that using an extra field in the CSOUND structure? We'll need an  
API function to get the size of spin.
On 5 Dec 2009, at 19:02, john ffitch wrote:

>>>>>> "fons" == fons   writes:
>
> fons> Hello all,
> fons> Is there any chance of Csound ever allowing a different
> fons> number of input and output channels, in particular when
> fons> used with Jack ? It's somehow absurd to have 64 inputs
> fons> when you only need 2. Or the inverse.
>
> I have been looking into this.  I have a test version that has a new
> header statement
>       nchns_i = 4
> that allocates spin of this size.  Idea is to default to nchns as at
> present.  I suspect it might need a API upgrade, but I think I can
> accommodate it.  So far I have been separating use, but keeping the
> same location via a macro.  Code is committed top CVS so anyone can
> correct or criticise.  Depends on how long the marking takes.....
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

also, we'll have to make sure that this change is also acknowledged by  
the IO plugins.
On 5 Dec 2009, at 19:02, john ffitch wrote:

>>>>>> "fons" == fons   writes:
>
> fons> Hello all,
> fons> Is there any chance of Csound ever allowing a different
> fons> number of input and output channels, in particular when
> fons> used with Jack ? It's somehow absurd to have 64 inputs
> fons> when you only need 2. Or the inverse.
>
> I have been looking into this.  I have a test version that has a new
> header statement
>       nchns_i = 4
> that allocates spin of this size.  Idea is to default to nchns as at
> present.  I suspect it might need a API upgrade, but I think I can
> accommodate it.  So far I have been separating use, but keeping the
> same location via a macro.  Code is committed top CVS so anyone can
> correct or criticise.  Depends on how long the marking takes.....
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

this won't break rtaudio callbacks and such?

wouldn't it be safer just to use audio bus channels?

On Dec 5, 2009, at 11:17 AM, Victor Lazzarini wrote:

> also, we'll have to make sure that this change is also acknowledged by  
> the IO plugins.
> On 5 Dec 2009, at 19:02, john ffitch wrote:
> 
>>>>>>> "fons" == fons   writes:
>> 
>> fons> Hello all,
>> fons> Is there any chance of Csound ever allowing a different
>> fons> number of input and output channels, in particular when
>> fons> used with Jack ? It's somehow absurd to have 64 inputs
>> fons> when you only need 2. Or the inverse.
>> 
>> I have been looking into this.  I have a test version that has a new
>> header statement
>>      nchns_i = 4
>> that allocates spin of this size.  Idea is to default to nchns as at
>> present.  I suspect it might need a API upgrade, but I think I can
>> accommodate it.  So far I have been separating use, but keeping the
>> same location via a macro.  Code is committed top CVS so anyone can
>> correct or criticise.  Depends on how long the marking takes.....
>> 
>> ==John ffitch
>> 
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



matt ingalls
matt@sonomatics.com




------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net