That is exactly what I meant, my apologies for not reading further in the manual. I have used the chn opcodes for control, but not for signal routing.

Now I am going to reconsider the way I have designed my "standard orchestra."

But I still wonder if there is a place for "inlets" and "outlets." I think the abstractions could perhaps be made a little more transparent in terms of DSP graph type networks. I will write up some dummy orchestras to see if I can come up with a completely self-explanatory Csound-type syntax for DSP graphs with "effects" and "instruments."

One feature of my prototype approach is that instruments do not need to be numbered. The orchestra compiler deduces the order of execution from the connection topology.

Thanks,
Mike

-----Original Message-----
>From: Victor Lazzarini 
>Sent: Sep 13, 2007 9:01 AM
>To: Developer discussions 
>Subject: Re: [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
>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