Csound Csound-dev Csound-tekno Search About

Re: [Cs-dev] Engine Changes, or Csound 6 (was Re: [Csnd] feature request: multiple strings in"i" statements)

Date2007-09-13 13:28
From"Michael Gogins"
SubjectRe: [Cs-dev] Engine Changes, or Csound 6 (was Re: [Csnd] feature request: multiple strings in"i" statements)
By the way, it is true that the software bus in Csound provides essentially 
the same facilities as my proposed "inlet" and "outlet" opcodes.

There is one difference, namely that the sink "inlet" opcodes would 
automatically sum any number of source "outlets". Can the bus do this?

Regards,
Mike

----- Original Message ----- 
From: "Victor Lazzarini" 
To: "Developer discussions" 
Sent: Thursday, September 13, 2007 4:28 AM
Subject: Re: [Cs-dev] Engine Changes, or Csound 6 (was Re: [Csnd] feature 
request: multiple strings in"i" statements)


>
>>
>>One of the main (and more irritating) limitations I find in csound is
>>the lack of routing abilities. The only way (that I know) of doing
>>some routing right now is an ugly hack involving global variables in
>>the orc file. Ideally, I would be able to create an "instrument" that
>>merely performs transformations on input. Then I could plug it in and
>>out to other instruments at play time, without having to stick the
>>transformation into a copy of the original instruments, or use the
>>mentioned hack above.
>
> But you don't need to use global variables; you can use
> the channel bus for instance (chn* opcodes), or the mixer opcodes that
> Mike Gogins has created. Would these not do what you want?
>
>>Having this kind of ability also opens up the possibility of easy
>>creation and sharing of effect processors: eg, I may find that a
>>certain combination of opcodes with such and such parameters sounds
>>like an awesome filter for my guitar, and publish it so that others
>>may just incorporate them in their orc/sco and try it out without
>>needing to modify existing instruments.
>
> But you can also use UDOs to share code without having to
> share whole instruments or orchestras.
>
>
>>Although reading the rest of your mail suggests that you can already
>>do this programmatically, it is much simpler for most cases to use a
>>specialized language rather than a Turing-complete one.
>
> True. I agree.
>
> Victor
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2007-09-13 14:01
FromVictor Lazzarini
SubjectRe: [Cs-dev] Engine Changes, or Csound 6 (was Re: [Csnd] feature request: multiple strings in"i" statements)
chnmix will mix a signal to the bus, is that what you mean?

At 13:28 13/09/2007, you wrote:
>By the way, it is true that the software bus in Csound provides essentially
>the same facilities as my proposed "inlet" and "outlet" opcodes.
>
>There is one difference, namely that the sink "inlet" opcodes would
>automatically sum any number of source "outlets". Can the bus do this?
>
>Regards,
>Mike
>
>----- Original Message -----
>From: "Victor Lazzarini" 
>To: "Developer discussions" 
>Sent: Thursday, September 13, 2007 4:28 AM
>Subject: Re: [Cs-dev] Engine Changes, or Csound 6 (was Re: [Csnd] feature
>request: multiple strings in"i" statements)
>
>
> >
> >>
> >>One of the main (and more irritating) limitations I find in csound is
> >>the lack of routing abilities. The only way (that I know) of doing
> >>some routing right now is an ugly hack involving global variables in
> >>the orc file. Ideally, I would be able to create an "instrument" that
> >>merely performs transformations on input. Then I could plug it in and
> >>out to other instruments at play time, without having to stick the
> >>transformation into a copy of the original instruments, or use the
> >>mentioned hack above.
> >
> > But you don't need to use global variables; you can use
> > the channel bus for instance (chn* opcodes), or the mixer opcodes that
> > Mike Gogins has created. Would these not do what you want?
> >
> >>Having this kind of ability also opens up the possibility of easy
> >>creation and sharing of effect processors: eg, I may find that a
> >>certain combination of opcodes with such and such parameters sounds
> >>like an awesome filter for my guitar, and publish it so that others
> >>may just incorporate them in their orc/sco and try it out without
> >>needing to modify existing instruments.
> >
> > But you can also use UDOs to share code without having to
> > share whole instruments or orchestras.
> >
> >
> >>Although reading the rest of your mail suggests that you can already
> >>do this programmatically, it is much simpler for most cases to use a
> >>specialized language rather than a Turing-complete one.
> >
> > True. I agree.
> >
> > Victor
> > Victor Lazzarini
> > Music Technology Laboratory
> > Music Department
> > National University of Ireland, Maynooth
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net