I agree that this is an irritating limitation of Csound. 

My prototype synthesizer silencevst has this feature, which was inspired by the impressive tracker Buzz.

This feature could be added to Csound without breaking backward compatibility, by defining some new opcodes and orchestra syntax.

New opcodes:

xvalue inlet, iname
outlet iname, xvalue

Usage:

instr 1
asignal inlet "audioInput"
asignal = asignal * 2.0
outlet "audioOutput", asignal
endin

New global orchestra connection opcode (placed after all instr definitions):

connect 1, "audioInput", 2, "audioOutput" ; connect instr 2 outlet "audioOutput" to instr 1 inlet "audioInput"

Or connections could be done in the instrument definition, with outlet arguments to inlet opcodes:

instr 2
asignal inlet "audioInput", 1, "audioOutput" ; connect "audioOutput" outlet of instr 1  to this inlet
out asignal
endin

Perhaps something less clunky could be developed, but this would work well enough. For polyphonic instruments, all signals would be summed. And for multiple outlets connected to one inlet, all signals would be summed.

The in* and out* opcodes could then be re-implemented as the arate inlets and outlets of the global instrument, by default connected to all instruments.
 
Regards,
Mike

-----Original Message-----
>From: Felipe Sateler 
>Sent: Sep 12, 2007 2:08 PM
>To: Developer discussions 
>Subject: Re: [Cs-dev] Engine Changes,	or Csound 6 (was Re: [Csnd] feature request: multiple strings in"i"	statements)
>
>Chipping my $0.02 in.
>
>On 9/12/07, Victor Lazzarini  wrote:
>
>>
>> >I know that there are tools to generate SCO files (and maybe some
>> >ORC?) from other sources, but I think that there are some problems
>> >that prevent this from really being a suitable solution.  A principle
>> >one for me is the "portamento problem": Roughly, I want to be able to
>> >control the parameters (frequency, for example) of a "note" while it's
>> >playing, from the "score" file, in a natural way and without having to
>> >specially prepare the instrument.  As far as I can tell, this simply
>> >isn't possible currently in cscore.
>>
>> yes, but you can use a lot of other means of doing it as outlined
>> above. But even using the standard score you can do it by
>> taking advantage of the tie and indefinite duration system (with negative
>> p3), which has actually been there from the very beginning.
>
>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.
>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.
>
>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.
>
>-- 
>
>	Felipe Sateler
>
>-------------------------------------------------------------------------
>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

I designed something like this in Csound using strings and the chn opcodes. 
I still have quite a bit of work with it, as it's pretty clunky at the
moment.  The good news is, that there is already a working Csound prototype.

http://www.thumbuki.com/csound/files/thumbuki20070702.csd

I'll work on a more refined example when I get a chance.

Best,
Jake

---- 
The Csound Blog 
http://www.thumbuki.com/csound/blog  




Michael Gogins wrote:
> 
> I agree that this is an irritating limitation of Csound. 
> 
> My prototype synthesizer silencevst has this feature, which was inspired
> by the impressive tracker Buzz.
> 
> This feature could be added to Csound without breaking backward
> compatibility, by defining some new opcodes and orchestra syntax.
> 
> New opcodes:
> 
> xvalue inlet, iname
> outlet iname, xvalue
> 
> Usage:
> 
> instr 1
> asignal inlet "audioInput"
> asignal = asignal * 2.0
> outlet "audioOutput", asignal
> endin
> 
> New global orchestra connection opcode (placed after all instr
> definitions):
> 
> connect 1, "audioInput", 2, "audioOutput" ; connect instr 2 outlet
> "audioOutput" to instr 1 inlet "audioInput"
> 
> Or connections could be done in the instrument definition, with outlet
> arguments to inlet opcodes:
> 
> instr 2
> asignal inlet "audioInput", 1, "audioOutput" ; connect "audioOutput"
> outlet of instr 1  to this inlet
> out asignal
> endin
> 
> Perhaps something less clunky could be developed, but this would work well
> enough. For polyphonic instruments, all signals would be summed. And for
> multiple outlets connected to one inlet, all signals would be summed.
> 
> The in* and out* opcodes could then be re-implemented as the arate inlets
> and outlets of the global instrument, by default connected to all
> instruments.
>  
> Regards,
> Mike
> 
> -----Original Message-----
>>From: Felipe Sateler 
>>Sent: Sep 12, 2007 2:08 PM
>>To: Developer discussions 
>>Subject: Re: [Cs-dev] Engine Changes,	or Csound 6 (was Re: [Csnd] feature
request: multiple strings in"i"	statements)
>>
>>Chipping my $0.02 in.
>>
>>On 9/12/07, Victor Lazzarini  wrote:
>>
>>>
>>> >I know that there are tools to generate SCO files (and maybe some
>>> >ORC?) from other sources, but I think that there are some problems
>>> >that prevent this from really being a suitable solution.  A principle
>>> >one for me is the "portamento problem": Roughly, I want to be able to
>>> >control the parameters (frequency, for example) of a "note" while it's
>>> >playing, from the "score" file, in a natural way and without having to
>>> >specially prepare the instrument.  As far as I can tell, this simply
>>> >isn't possible currently in cscore.
>>>
>>> yes, but you can use a lot of other means of doing it as outlined
>>> above. But even using the standard score you can do it by
>>> taking advantage of the tie and indefinite duration system (with
>>> negative
>>> p3), which has actually been there from the very beginning.
>>
>>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.
>>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.
>>
>>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.
>>
>>-- 
>>
>>	Felipe Sateler
>>
>>-------------------------------------------------------------------------
>>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
> 
> 

-- 
View this message in context: http://www.nabble.com/Re%3A-Engine-Changes%2C-or-Csound-6-%28was-Re%3A--Csnd--feature-request%3A-multiple-strings-in-tf4423300.html#a12646144
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
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

yes, people forget the busses. And Matt's subinstr stuff.

At 00:04 13/09/2007, you wrote:

>>>This feature could be added to Csound without breaking backward
>>>compatibility, by defining some new opcodes and orchestra syntax.
>>>
>>>New opcodes:
>>>
>>>xval e inlet, iname
>>>outlet iname, xvalue
>
>well isn't this what the current bussing system does?
>
>and zak, and invalue/outvalue opcodes (although would need to add some 
>internal code for storing the data
>instead of relying on the other side of the API -- i have volunteered to 
>add my code for this many
>times but noone seemed interested)
>
>personally, i would rather just have ONE "in" and "out" opcode pair that 
>can be used
>for all variable types/rates.  they would default to how they work now for 
>backwards compatibility, and
>then there could be new opcodes for routing and creating channels.
>
i should also remind you all here, that you can use a named instrument as a 
subroutine, which may
be related to the problems you are talking about ( i have been on the road 
and missed much of this thread )


instr mySine
asig sin 100
out asig
endin

instr 1
asig mySine
out asig
endin


matt ingalls
development@gvox.com



-------------------------------------------------------------------------
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

I didn't know one could do that. The code Matt posted doesn't work for 
me here, can anyone post a working example? I keep getting errors 
whenever I try to call my instruments name within another instrument? 
Cheers,
Rory.


 >be related to the problems you are talking about ( i have been on the 
 >road and missed much of this thread )
 >
 >
 >
 >instr mySine
 >asig sin 100
 >out asig
 >endin
 >
 >instr 1
 >asig mySine
 >out asig
 >endin

-------------------------------------------------------------------------
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

Sorry to come late to this, but how does this differ from the
software bus?
==John ffitch

-------------------------------------------------------------------------
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