I have made some progress in implementing these opcodes. I have decided that 
for now the proposed pmap opcode is not feasible; at least, the concept is 
not feasible purely as an opcode.

I believe all the other features can be implemented using only opcodes. This 
work has caused me to refine the specification somewhat, see below.

Regards,
Mike

/**
 * T H E   S I G N A L   F L O W   G R A P H
 * F A M I L Y   O F   O P C O D E S
 *
 * Michael Gogins
 *
 * These opcodes enable the declaration
 * of signal flow graphs (AKA asynchronous data flow graphs)
 * in Csound orchestras. Signals flow
 * from the outlets of source instruments
 * to the inlets of sink instruments.
 * Signals may be k-rate, a-rate, or f-rate.
 * Any number of outlets may be connected
 * to any number of inlets. When a new instance
 * of an instrument is instantiated
 * during performance, the declared connections also
 * are automatically instantiated.
 *
 * Signal flow graphs simplify the construction of complex mixers,
 * signal processing chains, and the like. They also simplify the
 * re-use of instrument definitions and even entire orchestras,
 * which can simply be #included and then "plugged in"
 * to existing orchestras.
 *
 * Instruments must be named, and each source instrument
 * must be defined in the orchestra before any of its sinks.
 * The reason instruments must be named is so that
 * outlets and inlets in any higher-level orchestra can
 * be connected to inlets and outlets in any lower-level
 * #included orchestra.
 *
 * O P C O D E S
 *
 * signalflowgraph
 *
 * Initializes the signal flow graph; must be declared once
 * and only once in the top-level orchestra,
 * before any of the other signal flow graph opcodes.
 *
 * outleta Sname, asignal
 * outletk Sname, ksignal
 * outletf Sname, fsignal
 *
 * Outlets send a, k, or f-rate signals out from an instrument.
 *
 * The name of the outlet is implicitly qualified by the instrument name,
 * so it is valid to use the same outlet name in more than one instrument
 * (but not to use the same outlet name twice in the same instrument).
 *
 * asignal inleta Sname
 * ksignal inletk Sname
 * fsignal inletf Sname
 *
 * Inlets receive a, k, or f-rate signals from outlets in other instruments.
 * The signals from all the source outlet instances are summed
 * in each sink inlet instance.
 *
 * The name of the inlet is implicitly qualified by the instrument name,
 * so it is valid to use the same inlet name in more than one instrument
 * (but not to use the same inlet name twice in the same instrument).
 *
 * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1, 
Sinlet2] ...]]
 *
 * The connect opcode, valid only in orchestra headers, sends the signals
 * from the indicated outlets in all instances of the indicated source
 * instrument to the indicated inlets in all instances of the indicated sink
 * instrument.
 *
 * alwayson Sinstrumentname [p4, ..., pn]
 *
 * Activates the indicated instrument in the orchestra header,
 * without need for an i statement. Instruments must be
 * activated in the same order as they are defined.
 *
 * The alwayson opcode is designed to simplify
 * the definition of re-usable orchestras with
 * signal processing or effects chains and networks.
 *
 * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is -1.
 * The optional pfields are sent to the instrument following p3.
 *
 * ifno ftgenonce isize, igen [, iarga, iargb, ...]
 *
 * Enables the creation of function tables
 * entirely inside instrument definitions,
 * without any duplication of data.
 *
 * The ftgenonce opcode is designed to simplify
 * writing instrument definitions that can be
 * re-used in different orchestras simply by #including them
 * and plugging them into some output instrument.
 * There is no need to define function tables
 * either in the score, or in the orchestra header.
 *
 * The ftgenonce opcode is similar to ftgentmp,
 * except that function tables are neither
 * duplicated nor deleted. Instead, all of the arguments
 * to the opcode are concatenated to form the key
 * to a lookup table that points to the function
 * table structure. Every request to ftgenonce
 * with the same arguments receives the same
 * instance of the function table data.
 * Every change in the value of any ftgenonce argument
 * causes the creation of a new function table.
 */




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Mike, do you have some simple examples illustrating their use?

2009/9/16  :
> I have made some progress in implementing these opcodes. I have decided that
> for now the proposed pmap opcode is not feasible; at least, the concept is
> not feasible purely as an opcode.
>
> I believe all the other features can be implemented using only opcodes. This
> work has caused me to refine the specification somewhat, see below.
>
> Regards,
> Mike
>
> /**
> * T H E   S I G N A L   F L O W   G R A P H
> * F A M I L Y   O F   O P C O D E S
> *
> * Michael Gogins
> *
> * These opcodes enable the declaration
> * of signal flow graphs (AKA asynchronous data flow graphs)
> * in Csound orchestras. Signals flow
> * from the outlets of source instruments
> * to the inlets of sink instruments.
> * Signals may be k-rate, a-rate, or f-rate.
> * Any number of outlets may be connected
> * to any number of inlets. When a new instance
> * of an instrument is instantiated
> * during performance, the declared connections also
> * are automatically instantiated.
> *
> * Signal flow graphs simplify the construction of complex mixers,
> * signal processing chains, and the like. They also simplify the
> * re-use of instrument definitions and even entire orchestras,
> * which can simply be #included and then "plugged in"
> * to existing orchestras.
> *
> * Instruments must be named, and each source instrument
> * must be defined in the orchestra before any of its sinks.
> * The reason instruments must be named is so that
> * outlets and inlets in any higher-level orchestra can
> * be connected to inlets and outlets in any lower-level
> * #included orchestra.
> *
> * O P C O D E S
> *
> * signalflowgraph
> *
> * Initializes the signal flow graph; must be declared once
> * and only once in the top-level orchestra,
> * before any of the other signal flow graph opcodes.
> *
> * outleta Sname, asignal
> * outletk Sname, ksignal
> * outletf Sname, fsignal
> *
> * Outlets send a, k, or f-rate signals out from an instrument.
> *
> * The name of the outlet is implicitly qualified by the instrument name,
> * so it is valid to use the same outlet name in more than one instrument
> * (but not to use the same outlet name twice in the same instrument).
> *
> * asignal inleta Sname
> * ksignal inletk Sname
> * fsignal inletf Sname
> *
> * Inlets receive a, k, or f-rate signals from outlets in other instruments.
> * The signals from all the source outlet instances are summed
> * in each sink inlet instance.
> *
> * The name of the inlet is implicitly qualified by the instrument name,
> * so it is valid to use the same inlet name in more than one instrument
> * (but not to use the same inlet name twice in the same instrument).
> *
> * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1,
> Sinlet2] ...]]
> *
> * The connect opcode, valid only in orchestra headers, sends the signals
> * from the indicated outlets in all instances of the indicated source
> * instrument to the indicated inlets in all instances of the indicated sink
> * instrument.
> *
> * alwayson Sinstrumentname [p4, ..., pn]
> *
> * Activates the indicated instrument in the orchestra header,
> * without need for an i statement. Instruments must be
> * activated in the same order as they are defined.
> *
> * The alwayson opcode is designed to simplify
> * the definition of re-usable orchestras with
> * signal processing or effects chains and networks.
> *
> * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is -1.
> * The optional pfields are sent to the instrument following p3.
> *
> * ifno ftgenonce isize, igen [, iarga, iargb, ...]
> *
> * Enables the creation of function tables
> * entirely inside instrument definitions,
> * without any duplication of data.
> *
> * The ftgenonce opcode is designed to simplify
> * writing instrument definitions that can be
> * re-used in different orchestras simply by #including them
> * and plugging them into some output instrument.
> * There is no need to define function tables
> * either in the score, or in the orchestra header.
> *
> * The ftgenonce opcode is similar to ftgentmp,
> * except that function tables are neither
> * duplicated nor deleted. Instead, all of the arguments
> * to the opcode are concatenated to form the key
> * to a lookup table that points to the function
> * table structure. Every request to ftgenonce
> * with the same arguments receives the same
> * instance of the function table data.
> * Every change in the value of any ftgenonce argument
> * causes the creation of a new function table.
> */
>
>
>
>
> 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"

As soon as I get them working I will have examples.

Mkg

On Sep 16, 2009 7:28 AM, "Rory Walsh" <rorywalsh@ear.ie> wrote:

Hi Mike, do you have some simple examples illustrating their use?

2009/9/16  <michael.gogins@gmail.com>:

> I have made some progress in implementing these opcodes. I have decided that > for now the propose...

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

Great, I thought that they were already good to go. I look forward to
trying them once they are.

2009/9/16 Michael Gogins :
> As soon as I get them working I will have examples.
>
> Mkg
>
> On Sep 16, 2009 7:28 AM, "Rory Walsh"  wrote:
>
> Hi Mike, do you have some simple examples illustrating their use?
>
> 2009/9/16  :
>
>> I have made some progress in implementing these opcodes. I have decided
>> that > for now the propose...
>
>> 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"

Hi Michael,

I'm just getting around to looking at the proposal with attention now.
 I'm finding that the inlet/outlet opcodes function similarly to what
I do already with blue compiling down to global vars, though may be
easier to use for hand-coding.  A couple of questions:

1. Does inlet/outlet bus clear itself after each kpass?
2. Can outlets be connected to multiple inlets? I'm wondering about
the situation where a dry signal and a wet signal processed by another
instrument could be routed to 3rd instrument.  In real usage though, I
imagine it might not be a big deal if instruments plug themselves to
large mixer instrument where once the signal is within the mixer
instrument, the mixer code could process the signals ad-hoc within it.
3. One minor deficiency with blue at the moment is that for every
instrument or effect that has an automatable value, blue generates a
specific control instrument that is used with score statements. The
control instrument currently just does either single one-time setting
of values or linear setting over time. However, since blue uses global
sigs at the moment, a control instrument is required per parameter.
Using connect requires a static connection, so to achieve the same
thing with your proposed opcodes would require additional code to
connect generated signals and sinks and that can not be done per-note.

Because of 3 above, I'm wondering about explicit connections versus a
more publish/subscribe type of system. It makes sense at least for
k-sigs.  Using chnset/chnget should work fine in this scenario, so one
instrument can write to a channel and another can listen, and the
listening instrument doesn't really care what is connected to it but
rather is on a channel. (I should probably rewrite blue to use
this...).

steven

On Tue, Sep 15, 2009 at 9:44 PM,   wrote:
> I have made some progress in implementing these opcodes. I have decided that
> for now the proposed pmap opcode is not feasible; at least, the concept is
> not feasible purely as an opcode.
>
> I believe all the other features can be implemented using only opcodes. This
> work has caused me to refine the specification somewhat, see below.
>
> Regards,
> Mike
>
> /**
> * T H E   S I G N A L   F L O W   G R A P H
> * F A M I L Y   O F   O P C O D E S
> *
> * Michael Gogins
> *
> * These opcodes enable the declaration
> * of signal flow graphs (AKA asynchronous data flow graphs)
> * in Csound orchestras. Signals flow
> * from the outlets of source instruments
> * to the inlets of sink instruments.
> * Signals may be k-rate, a-rate, or f-rate.
> * Any number of outlets may be connected
> * to any number of inlets. When a new instance
> * of an instrument is instantiated
> * during performance, the declared connections also
> * are automatically instantiated.
> *
> * Signal flow graphs simplify the construction of complex mixers,
> * signal processing chains, and the like. They also simplify the
> * re-use of instrument definitions and even entire orchestras,
> * which can simply be #included and then "plugged in"
> * to existing orchestras.
> *
> * Instruments must be named, and each source instrument
> * must be defined in the orchestra before any of its sinks.
> * The reason instruments must be named is so that
> * outlets and inlets in any higher-level orchestra can
> * be connected to inlets and outlets in any lower-level
> * #included orchestra.
> *
> * O P C O D E S
> *
> * signalflowgraph
> *
> * Initializes the signal flow graph; must be declared once
> * and only once in the top-level orchestra,
> * before any of the other signal flow graph opcodes.
> *
> * outleta Sname, asignal
> * outletk Sname, ksignal
> * outletf Sname, fsignal
> *
> * Outlets send a, k, or f-rate signals out from an instrument.
> *
> * The name of the outlet is implicitly qualified by the instrument name,
> * so it is valid to use the same outlet name in more than one instrument
> * (but not to use the same outlet name twice in the same instrument).
> *
> * asignal inleta Sname
> * ksignal inletk Sname
> * fsignal inletf Sname
> *
> * Inlets receive a, k, or f-rate signals from outlets in other instruments.
> * The signals from all the source outlet instances are summed
> * in each sink inlet instance.
> *
> * The name of the inlet is implicitly qualified by the instrument name,
> * so it is valid to use the same inlet name in more than one instrument
> * (but not to use the same inlet name twice in the same instrument).
> *
> * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1,
> Sinlet2] ...]]
> *
> * The connect opcode, valid only in orchestra headers, sends the signals
> * from the indicated outlets in all instances of the indicated source
> * instrument to the indicated inlets in all instances of the indicated sink
> * instrument.
> *
> * alwayson Sinstrumentname [p4, ..., pn]
> *
> * Activates the indicated instrument in the orchestra header,
> * without need for an i statement. Instruments must be
> * activated in the same order as they are defined.
> *
> * The alwayson opcode is designed to simplify
> * the definition of re-usable orchestras with
> * signal processing or effects chains and networks.
> *
> * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is -1.
> * The optional pfields are sent to the instrument following p3.
> *
> * ifno ftgenonce isize, igen [, iarga, iargb, ...]
> *
> * Enables the creation of function tables
> * entirely inside instrument definitions,
> * without any duplication of data.
> *
> * The ftgenonce opcode is designed to simplify
> * writing instrument definitions that can be
> * re-used in different orchestras simply by #including them
> * and plugging them into some output instrument.
> * There is no need to define function tables
> * either in the score, or in the orchestra header.
> *
> * The ftgenonce opcode is similar to ftgentmp,
> * except that function tables are neither
> * duplicated nor deleted. Instead, all of the arguments
> * to the opcode are concatenated to form the key
> * to a lookup table that points to the function
> * table structure. Every request to ftgenonce
> * with the same arguments receives the same
> * instance of the function table data.
> * Every change in the value of any ftgenonce argument
> * causes the creation of a new function table.
> */
>
>
>
>
> 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, too, am looking forward to seeing them in action.

I have a question in terms of releasing these opcodes.  Is it possible that
they make into the next version so we can try them out?  If yes, can they
released with the condition that they are still in development and subject
to change?

As we all know, once something is in Csound, it's in Csound forever.  The
functionality that these opcodes bring to Csound are too important to
finalize without thoroughly testing them.

Best,
Jake




RoryWalsh wrote:
> 
> Great, I thought that they were already good to go. I look forward to
> trying them once they are.
> 
> 2009/9/16 Michael Gogins :
>> As soon as I get them working I will have examples.
>>
>> Mkg
>>
>> On Sep 16, 2009 7:28 AM, "Rory Walsh"  wrote:
>>
>> Hi Mike, do you have some simple examples illustrating their use?
>>
>> 2009/9/16  :
>>
>>> I have made some progress in implementing these opcodes. I have decided
>>> that > for now the propose...
>>
>>> 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"
> 

-- 
View this message in context: http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25474785.html
Sent from the Csound - General mailing list archive at Nabble.com.



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Well, they could just be released as a separate opcode library for testing.

On Wed, Sep 16, 2009 at 11:25 AM, Jacob Joaquin  wrote:
>
> I, too, am looking forward to seeing them in action.
>
> I have a question in terms of releasing these opcodes.  Is it possible that
> they make into the next version so we can try them out?  If yes, can they
> released with the condition that they are still in development and subject
> to change?
>
> As we all know, once something is in Csound, it's in Csound forever.  The
> functionality that these opcodes bring to Csound are too important to
> finalize without thoroughly testing them.
>
> Best,
> Jake
>
>
>
>
> RoryWalsh wrote:
>>
>> Great, I thought that they were already good to go. I look forward to
>> trying them once they are.
>>
>> 2009/9/16 Michael Gogins :
>>> As soon as I get them working I will have examples.
>>>
>>> Mkg
>>>
>>> On Sep 16, 2009 7:28 AM, "Rory Walsh"  wrote:
>>>
>>> Hi Mike, do you have some simple examples illustrating their use?
>>>
>>> 2009/9/16  :
>>>
>>>> I have made some progress in implementing these opcodes. I have decided
>>>> that > for now the propose...
>>>
>>>> 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"
>>
>
> --
> View this message in context: http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25474785.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> 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"

That would work, too.  I just want to make sure we don't rush this thing out
the door before it's ready.

Best,
Jake



Steven Yi wrote:
> 
> Well, they could just be released as a separate opcode library for
> testing.
> 
> On Wed, Sep 16, 2009 at 11:25 AM, Jacob Joaquin 
> wrote:
>>
>> I, too, am looking forward to seeing them in action.
>>
>> I have a question in terms of releasing these opcodes.  Is it possible
>> that
>> they make into the next version so we can try them out?  If yes, can they
>> released with the condition that they are still in development and
>> subject
>> to change?
>>
>> As we all know, once something is in Csound, it's in Csound forever.  The
>> functionality that these opcodes bring to Csound are too important to
>> finalize without thoroughly testing them.
>>
>> Best,
>> Jake
>>
>>
>>
>>
>> RoryWalsh wrote:
>>>
>>> Great, I thought that they were already good to go. I look forward to
>>> trying them once they are.
>>>
>>> 2009/9/16 Michael Gogins :
>>>> As soon as I get them working I will have examples.
>>>>
>>>> Mkg
>>>>
>>>> On Sep 16, 2009 7:28 AM, "Rory Walsh"  wrote:
>>>>
>>>> Hi Mike, do you have some simple examples illustrating their use?
>>>>
>>>> 2009/9/16  :
>>>>
>>>>> I have made some progress in implementing these opcodes. I have
>>>>> decided
>>>>> that > for now the propose...
>>>>
>>>>> 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"
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25474785.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> 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"
> 

-- 
View this message in context: http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25474897.html
Sent from the Csound - General mailing list archive at Nabble.com.



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks for your thoughts.

Re (1): Yes, outlets and inlets automatically clear after each kperiod.

Re (2): Yes, any number of outlets can be connected to any number of
inlets; there is both fan-in, and fan-out.

Re (3): I hadn't thought of this case. I will think about what, if
anything, to do about it.

Best,
Mike

On 9/16/09, Steven Yi  wrote:
> Hi Michael,
>
> I'm just getting around to looking at the proposal with attention now.
>  I'm finding that the inlet/outlet opcodes function similarly to what
> I do already with blue compiling down to global vars, though may be
> easier to use for hand-coding.  A couple of questions:
>
> 1. Does inlet/outlet bus clear itself after each kpass?
> 2. Can outlets be connected to multiple inlets? I'm wondering about
> the situation where a dry signal and a wet signal processed by another
> instrument could be routed to 3rd instrument.  In real usage though, I
> imagine it might not be a big deal if instruments plug themselves to
> large mixer instrument where once the signal is within the mixer
> instrument, the mixer code could process the signals ad-hoc within it.
> 3. One minor deficiency with blue at the moment is that for every
> instrument or effect that has an automatable value, blue generates a
> specific control instrument that is used with score statements. The
> control instrument currently just does either single one-time setting
> of values or linear setting over time. However, since blue uses global
> sigs at the moment, a control instrument is required per parameter.
> Using connect requires a static connection, so to achieve the same
> thing with your proposed opcodes would require additional code to
> connect generated signals and sinks and that can not be done per-note.
>
> Because of 3 above, I'm wondering about explicit connections versus a
> more publish/subscribe type of system. It makes sense at least for
> k-sigs.  Using chnset/chnget should work fine in this scenario, so one
> instrument can write to a channel and another can listen, and the
> listening instrument doesn't really care what is connected to it but
> rather is on a channel. (I should probably rewrite blue to use
> this...).
>
> steven
>
> On Tue, Sep 15, 2009 at 9:44 PM,   wrote:
>> I have made some progress in implementing these opcodes. I have decided
>> that
>> for now the proposed pmap opcode is not feasible; at least, the concept is
>> not feasible purely as an opcode.
>>
>> I believe all the other features can be implemented using only opcodes.
>> This
>> work has caused me to refine the specification somewhat, see below.
>>
>> Regards,
>> Mike
>>
>> /**
>> * T H E   S I G N A L   F L O W   G R A P H
>> * F A M I L Y   O F   O P C O D E S
>> *
>> * Michael Gogins
>> *
>> * These opcodes enable the declaration
>> * of signal flow graphs (AKA asynchronous data flow graphs)
>> * in Csound orchestras. Signals flow
>> * from the outlets of source instruments
>> * to the inlets of sink instruments.
>> * Signals may be k-rate, a-rate, or f-rate.
>> * Any number of outlets may be connected
>> * to any number of inlets. When a new instance
>> * of an instrument is instantiated
>> * during performance, the declared connections also
>> * are automatically instantiated.
>> *
>> * Signal flow graphs simplify the construction of complex mixers,
>> * signal processing chains, and the like. They also simplify the
>> * re-use of instrument definitions and even entire orchestras,
>> * which can simply be #included and then "plugged in"
>> * to existing orchestras.
>> *
>> * Instruments must be named, and each source instrument
>> * must be defined in the orchestra before any of its sinks.
>> * The reason instruments must be named is so that
>> * outlets and inlets in any higher-level orchestra can
>> * be connected to inlets and outlets in any lower-level
>> * #included orchestra.
>> *
>> * O P C O D E S
>> *
>> * signalflowgraph
>> *
>> * Initializes the signal flow graph; must be declared once
>> * and only once in the top-level orchestra,
>> * before any of the other signal flow graph opcodes.
>> *
>> * outleta Sname, asignal
>> * outletk Sname, ksignal
>> * outletf Sname, fsignal
>> *
>> * Outlets send a, k, or f-rate signals out from an instrument.
>> *
>> * The name of the outlet is implicitly qualified by the instrument name,
>> * so it is valid to use the same outlet name in more than one instrument
>> * (but not to use the same outlet name twice in the same instrument).
>> *
>> * asignal inleta Sname
>> * ksignal inletk Sname
>> * fsignal inletf Sname
>> *
>> * Inlets receive a, k, or f-rate signals from outlets in other
>> instruments.
>> * The signals from all the source outlet instances are summed
>> * in each sink inlet instance.
>> *
>> * The name of the inlet is implicitly qualified by the instrument name,
>> * so it is valid to use the same inlet name in more than one instrument
>> * (but not to use the same inlet name twice in the same instrument).
>> *
>> * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1,
>> Sinlet2] ...]]
>> *
>> * The connect opcode, valid only in orchestra headers, sends the signals
>> * from the indicated outlets in all instances of the indicated source
>> * instrument to the indicated inlets in all instances of the indicated
>> sink
>> * instrument.
>> *
>> * alwayson Sinstrumentname [p4, ..., pn]
>> *
>> * Activates the indicated instrument in the orchestra header,
>> * without need for an i statement. Instruments must be
>> * activated in the same order as they are defined.
>> *
>> * The alwayson opcode is designed to simplify
>> * the definition of re-usable orchestras with
>> * signal processing or effects chains and networks.
>> *
>> * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is
>> -1.
>> * The optional pfields are sent to the instrument following p3.
>> *
>> * ifno ftgenonce isize, igen [, iarga, iargb, ...]
>> *
>> * Enables the creation of function tables
>> * entirely inside instrument definitions,
>> * without any duplication of data.
>> *
>> * The ftgenonce opcode is designed to simplify
>> * writing instrument definitions that can be
>> * re-used in different orchestras simply by #including them
>> * and plugging them into some output instrument.
>> * There is no need to define function tables
>> * either in the score, or in the orchestra header.
>> *
>> * The ftgenonce opcode is similar to ftgentmp,
>> * except that function tables are neither
>> * duplicated nor deleted. Instead, all of the arguments
>> * to the opcode are concatenated to form the key
>> * to a lookup table that points to the function
>> * table structure. Every request to ftgenonce
>> * with the same arguments receives the same
>> * instance of the function table data.
>> * Every change in the value of any ftgenonce argument
>> * causes the creation of a new function table.
>> */
>>
>>
>>
>>
>> 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 appreciate your concern for what gets into Csound, there is an
obvious potential for confusion.

I think the best way to handle such concerns is to put this kind of
new functionality into a public beta release. That is what I will do
with this. I already have a beta Windows installer for the next
release, so I will update that. Other platforms will have to build it,
but it will be in CVS.

Regards,
Mike

On 9/16/09, Jacob Joaquin  wrote:
>
> That would work, too.  I just want to make sure we don't rush this thing out
> the door before it's ready.
>
> Best,
> Jake
>
>
>
> Steven Yi wrote:
>>
>> Well, they could just be released as a separate opcode library for
>> testing.
>>
>> On Wed, Sep 16, 2009 at 11:25 AM, Jacob Joaquin 
>> wrote:
>>>
>>> I, too, am looking forward to seeing them in action.
>>>
>>> I have a question in terms of releasing these opcodes.  Is it possible
>>> that
>>> they make into the next version so we can try them out?  If yes, can they
>>> released with the condition that they are still in development and
>>> subject
>>> to change?
>>>
>>> As we all know, once something is in Csound, it's in Csound forever.  The
>>> functionality that these opcodes bring to Csound are too important to
>>> finalize without thoroughly testing them.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>>
>>>
>>> RoryWalsh wrote:
>>>>
>>>> Great, I thought that they were already good to go. I look forward to
>>>> trying them once they are.
>>>>
>>>> 2009/9/16 Michael Gogins :
>>>>> As soon as I get them working I will have examples.
>>>>>
>>>>> Mkg
>>>>>
>>>>> On Sep 16, 2009 7:28 AM, "Rory Walsh"  wrote:
>>>>>
>>>>> Hi Mike, do you have some simple examples illustrating their use?
>>>>>
>>>>> 2009/9/16  :
>>>>>
>>>>>> I have made some progress in implementing these opcodes. I have
>>>>>> decided
>>>>>> that > for now the propose...
>>>>>
>>>>>> 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"
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25474785.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> 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"
>>
>
> --
> View this message in context:
> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25474897.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

I've been making notes on how to deal with this issue in a new system.  Still
don't know what to do about it, though I have a few ideas.  In the past,
I've tried doing similar things with pure Csound, creating generic control
instruments that control multiple synth instrs independently if need be. 
Here are two examples, the first using zak and the second using chn:

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

Best,
Jake



Steven Yi wrote:
> 
> 3. One minor deficiency with blue at the moment is that for every
> instrument or effect that has an automatable value, blue generates a
> specific control instrument that is used with score statements. The
> control instrument currently just does either single one-time setting
> of values or linear setting over time. However, since blue uses global
> sigs at the moment, a control instrument is required per parameter.
> Using connect requires a static connection, so to achieve the same
> thing with your proposed opcodes would require additional code to
> connect generated signals and sinks and that can not be done per-note.
> 
> Because of 3 above, I'm wondering about explicit connections versus a
> more publish/subscribe type of system. It makes sense at least for
> k-sigs.  Using chnset/chnget should work fine in this scenario, so one
> instrument can write to a channel and another can listen, and the
> listening instrument doesn't really care what is connected to it but
> rather is on a channel. (I should probably rewrite blue to use
> this...).
> 

I've spent some time reading and re-reading your spec.  Very impressed with
it, as it covers much of the ground I was hoping a new patching system would
have.  In some cases, more.

I think I see a couple of potential issues, and I'm hoping you can clear a
couple of things up.

The first is named instruments.  I understand you are most likely aware of
the problems with named instruments, though it can't hurt to mention it.  If
an instrument is named, then users can no longer use a string as a pfield. 
This is a problem if one needs to use a pfield to specify the name of an
audio file in an i-event.  Signal flow graph or not, Csound would greatly
benefit from having this restriction removed, for a variety of reasons.

Another is the re-use of instruments/code.  If users needed to use two
instruments that were exactly the same in a graph, would they need to copy
and paste that instrument?  Or is there a mechanism/opcode/way to
auto-duplicate and re-use the same code base?  For example, if I wanted to
use two identical reverbs in a signalflowgraph, would I have to explicitly
write two copies like this?

    signalflowgraph
    
    instr "myVerb"
        ; code
    endin

    instr "myVerb2"
        ; duplicate code from "myVerb"
    endin
 
Best,
Jake


Michael Gogins-2 wrote:
> 
> I have made some progress in implementing these opcodes. I have decided
> that 
> for now the proposed pmap opcode is not feasible; at least, the concept is 
> not feasible purely as an opcode.
> 
> I believe all the other features can be implemented using only opcodes.
> This 
> work has caused me to refine the specification somewhat, see below.
> 
> Regards,
> Mike
> 
> /**
>  * T H E   S I G N A L   F L O W   G R A P H
>  * F A M I L Y   O F   O P C O D E S
>  *
>  * Michael Gogins
>  *
>  * These opcodes enable the declaration
>  * of signal flow graphs (AKA asynchronous data flow graphs)
>  * in Csound orchestras. Signals flow
>  * from the outlets of source instruments
>  * to the inlets of sink instruments.
>  * Signals may be k-rate, a-rate, or f-rate.
>  * Any number of outlets may be connected
>  * to any number of inlets. When a new instance
>  * of an instrument is instantiated
>  * during performance, the declared connections also
>  * are automatically instantiated.
>  *
>  * Signal flow graphs simplify the construction of complex mixers,
>  * signal processing chains, and the like. They also simplify the
>  * re-use of instrument definitions and even entire orchestras,
>  * which can simply be #included and then "plugged in"
>  * to existing orchestras.
>  *
>  * Instruments must be named, and each source instrument
>  * must be defined in the orchestra before any of its sinks.
>  * The reason instruments must be named is so that
>  * outlets and inlets in any higher-level orchestra can
>  * be connected to inlets and outlets in any lower-level
>  * #included orchestra.
>  *
>  * O P C O D E S
>  *
>  * signalflowgraph
>  *
>  * Initializes the signal flow graph; must be declared once
>  * and only once in the top-level orchestra,
>  * before any of the other signal flow graph opcodes.
>  *
>  * outleta Sname, asignal
>  * outletk Sname, ksignal
>  * outletf Sname, fsignal
>  *
>  * Outlets send a, k, or f-rate signals out from an instrument.
>  *
>  * The name of the outlet is implicitly qualified by the instrument name,
>  * so it is valid to use the same outlet name in more than one instrument
>  * (but not to use the same outlet name twice in the same instrument).
>  *
>  * asignal inleta Sname
>  * ksignal inletk Sname
>  * fsignal inletf Sname
>  *
>  * Inlets receive a, k, or f-rate signals from outlets in other
> instruments.
>  * The signals from all the source outlet instances are summed
>  * in each sink inlet instance.
>  *
>  * The name of the inlet is implicitly qualified by the instrument name,
>  * so it is valid to use the same inlet name in more than one instrument
>  * (but not to use the same inlet name twice in the same instrument).
>  *
>  * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1, 
> Sinlet2] ...]]
>  *
>  * The connect opcode, valid only in orchestra headers, sends the signals
>  * from the indicated outlets in all instances of the indicated source
>  * instrument to the indicated inlets in all instances of the indicated
> sink
>  * instrument.
>  *
>  * alwayson Sinstrumentname [p4, ..., pn]
>  *
>  * Activates the indicated instrument in the orchestra header,
>  * without need for an i statement. Instruments must be
>  * activated in the same order as they are defined.
>  *
>  * The alwayson opcode is designed to simplify
>  * the definition of re-usable orchestras with
>  * signal processing or effects chains and networks.
>  *
>  * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is
> -1.
>  * The optional pfields are sent to the instrument following p3.
>  *
>  * ifno ftgenonce isize, igen [, iarga, iargb, ...]
>  *
>  * Enables the creation of function tables
>  * entirely inside instrument definitions,
>  * without any duplication of data.
>  *
>  * The ftgenonce opcode is designed to simplify
>  * writing instrument definitions that can be
>  * re-used in different orchestras simply by #including them
>  * and plugging them into some output instrument.
>  * There is no need to define function tables
>  * either in the score, or in the orchestra header.
>  *
>  * The ftgenonce opcode is similar to ftgentmp,
>  * except that function tables are neither
>  * duplicated nor deleted. Instead, all of the arguments
>  * to the opcode are concatenated to form the key
>  * to a lookup table that points to the function
>  * table structure. Every request to ftgenonce
>  * with the same arguments receives the same
>  * instance of the function table data.
>  * Every change in the value of any ftgenonce argument
>  * causes the creation of a new function table.
>  */
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

Thanks for your very useful comments on my specification.

About named instruments, I was not aware of this limitation. It is
serious. I don't know what to do about it. I will see how easy it is
to remove this awkward limitation in the Csound engine.

About duplicate instances of the same instrument, this happens
automatically for regular instruments that allocate new instances for
score events. But you are correct that my specification does not allow
for re-using the same instrument definition under a different name.

I don't know how serious this is. I don't know what to do about it.
But I am thinking about it! The best I can do right now is declare the
body of the instrument, without instr or endin, in an #include file
and do this:

instr "reverb1"
#include "reverb_body.orc"
endin

instr "reverb2"
#include "reverb_boxy.orc"
endin

This is a hack, and I hope we can do better.

The situation is complicated by efforts to get the parser working well
enough to be the default. I am not about to make any changes that
might break something.

One thing I will certainly do is see if Csound exposes enough stuff so
that that opcodes can monkey with instrument templates. I have no idea
if this even practical right now, and I kind of doubt it. Still, it
would be nice. Then an opcode could find a template, make a copy of it
and rename it, and insert it in the chain.

Obviously, this would make an instrument template into a class and the
new template a new instance of that class, although it's not enough to
support inheritance.

Thanks again,

Mike

On 9/16/09, Jacob Joaquin  wrote:
>
> I've spent some time reading and re-reading your spec.  Very impressed with
> it, as it covers much of the ground I was hoping a new patching system would
> have.  In some cases, more.
>
> I think I see a couple of potential issues, and I'm hoping you can clear a
> couple of things up.
>
> The first is named instruments.  I understand you are most likely aware of
> the problems with named instruments, though it can't hurt to mention it.  If
> an instrument is named, then users can no longer use a string as a pfield.
> This is a problem if one needs to use a pfield to specify the name of an
> audio file in an i-event.  Signal flow graph or not, Csound would greatly
> benefit from having this restriction removed, for a variety of reasons.
>
> Another is the re-use of instruments/code.  If users needed to use two
> instruments that were exactly the same in a graph, would they need to copy
> and paste that instrument?  Or is there a mechanism/opcode/way to
> auto-duplicate and re-use the same code base?  For example, if I wanted to
> use two identical reverbs in a signalflowgraph, would I have to explicitly
> write two copies like this?
>
>     signalflowgraph
>
>     instr "myVerb"
>         ; code
>     endin
>
>     instr "myVerb2"
>         ; duplicate code from "myVerb"
>     endin
>
> Best,
> Jake
>
>
> Michael Gogins-2 wrote:
>>
>> I have made some progress in implementing these opcodes. I have decided
>> that
>> for now the proposed pmap opcode is not feasible; at least, the concept is
>>
>> not feasible purely as an opcode.
>>
>> I believe all the other features can be implemented using only opcodes.
>> This
>> work has caused me to refine the specification somewhat, see below.
>>
>> Regards,
>> Mike
>>
>> /**
>>  * T H E   S I G N A L   F L O W   G R A P H
>>  * F A M I L Y   O F   O P C O D E S
>>  *
>>  * Michael Gogins
>>  *
>>  * These opcodes enable the declaration
>>  * of signal flow graphs (AKA asynchronous data flow graphs)
>>  * in Csound orchestras. Signals flow
>>  * from the outlets of source instruments
>>  * to the inlets of sink instruments.
>>  * Signals may be k-rate, a-rate, or f-rate.
>>  * Any number of outlets may be connected
>>  * to any number of inlets. When a new instance
>>  * of an instrument is instantiated
>>  * during performance, the declared connections also
>>  * are automatically instantiated.
>>  *
>>  * Signal flow graphs simplify the construction of complex mixers,
>>  * signal processing chains, and the like. They also simplify the
>>  * re-use of instrument definitions and even entire orchestras,
>>  * which can simply be #included and then "plugged in"
>>  * to existing orchestras.
>>  *
>>  * Instruments must be named, and each source instrument
>>  * must be defined in the orchestra before any of its sinks.
>>  * The reason instruments must be named is so that
>>  * outlets and inlets in any higher-level orchestra can
>>  * be connected to inlets and outlets in any lower-level
>>  * #included orchestra.
>>  *
>>  * O P C O D E S
>>  *
>>  * signalflowgraph
>>  *
>>  * Initializes the signal flow graph; must be declared once
>>  * and only once in the top-level orchestra,
>>  * before any of the other signal flow graph opcodes.
>>  *
>>  * outleta Sname, asignal
>>  * outletk Sname, ksignal
>>  * outletf Sname, fsignal
>>  *
>>  * Outlets send a, k, or f-rate signals out from an instrument.
>>  *
>>  * The name of the outlet is implicitly qualified by the instrument name,
>>  * so it is valid to use the same outlet name in more than one instrument
>>  * (but not to use the same outlet name twice in the same instrument).
>>  *
>>  * asignal inleta Sname
>>  * ksignal inletk Sname
>>  * fsignal inletf Sname
>>  *
>>  * Inlets receive a, k, or f-rate signals from outlets in other
>> instruments.
>>  * The signals from all the source outlet instances are summed
>>  * in each sink inlet instance.
>>  *
>>  * The name of the inlet is implicitly qualified by the instrument name,
>>  * so it is valid to use the same inlet name in more than one instrument
>>  * (but not to use the same inlet name twice in the same instrument).
>>  *
>>  * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1,
>>
>> Sinlet2] ...]]
>>  *
>>  * The connect opcode, valid only in orchestra headers, sends the signals
>>  * from the indicated outlets in all instances of the indicated source
>>  * instrument to the indicated inlets in all instances of the indicated
>> sink
>>  * instrument.
>>  *
>>  * alwayson Sinstrumentname [p4, ..., pn]
>>  *
>>  * Activates the indicated instrument in the orchestra header,
>>  * without need for an i statement. Instruments must be
>>  * activated in the same order as they are defined.
>>  *
>>  * The alwayson opcode is designed to simplify
>>  * the definition of re-usable orchestras with
>>  * signal processing or effects chains and networks.
>>  *
>>  * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is
>> -1.
>>  * The optional pfields are sent to the instrument following p3.
>>  *
>>  * ifno ftgenonce isize, igen [, iarga, iargb, ...]
>>  *
>>  * Enables the creation of function tables
>>  * entirely inside instrument definitions,
>>  * without any duplication of data.
>>  *
>>  * The ftgenonce opcode is designed to simplify
>>  * writing instrument definitions that can be
>>  * re-used in different orchestras simply by #including them
>>  * and plugging them into some output instrument.
>>  * There is no need to define function tables
>>  * either in the score, or in the orchestra header.
>>  *
>>  * The ftgenonce opcode is similar to ftgentmp,
>>  * except that function tables are neither
>>  * duplicated nor deleted. Instead, all of the arguments
>>  * to the opcode are concatenated to form the key
>>  * to a lookup table that points to the function
>>  * table structure. Every request to ftgenonce
>>  * with the same arguments receives the same
>>  * instance of the function table data.
>>  * Every change in the value of any ftgenonce argument
>>  * causes the creation of a new function table.
>>  */
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25477811.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I've upgraded my py script to support importing classes from from external
files, and have created an example.  Here are the two source files:

http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/importing.csd
http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/fx_library.csd


When importing.csd is preprocessed with template.py, it selectively imports
classes from fx_library.csd, and creates a new csd.  From this, I created
temp.csd, which csound can run:

http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/temp.csd


Here is the complete zip, with template.py:
http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/ImportClasses.zip


I believe #include will only take us so far in terms of creating shareable
instruments, as there are some obvious limitations.  For example, #include
includes the entire file.  If there was a mechanism that could selectively
include instruments from external files, then that would really open up
instrument sharing.  A composition would also be an instrument library.

And I also implemented a version of alwayson.  Very useful!

Best,
Jake




Michael Gogins-2 wrote:
> 
> Thanks for your very useful comments on my specification.
> 
> About named instruments, I was not aware of this limitation. It is
> serious. I don't know what to do about it. I will see how easy it is
> to remove this awkward limitation in the Csound engine.
> 
> About duplicate instances of the same instrument, this happens
> automatically for regular instruments that allocate new instances for
> score events. But you are correct that my specification does not allow
> for re-using the same instrument definition under a different name.
> 
> I don't know how serious this is. I don't know what to do about it.
> But I am thinking about it! The best I can do right now is declare the
> body of the instrument, without instr or endin, in an #include file
> and do this:
> 
> instr "reverb1"
> #include "reverb_body.orc"
> endin
> 
> instr "reverb2"
> #include "reverb_boxy.orc"
> endin
> 
> This is a hack, and I hope we can do better.
> 
> The situation is complicated by efforts to get the parser working well
> enough to be the default. I am not about to make any changes that
> might break something.
> 
> One thing I will certainly do is see if Csound exposes enough stuff so
> that that opcodes can monkey with instrument templates. I have no idea
> if this even practical right now, and I kind of doubt it. Still, it
> would be nice. Then an opcode could find a template, make a copy of it
> and rename it, and insert it in the chain.
> 
> Obviously, this would make an instrument template into a class and the
> new template a new instance of that class, although it's not enough to
> support inheritance.
> 
> Thanks again,
> 
> Mike
> 
> On 9/16/09, Jacob Joaquin  wrote:
>>
>> I've spent some time reading and re-reading your spec.  Very impressed
>> with
>> it, as it covers much of the ground I was hoping a new patching system
>> would
>> have.  In some cases, more.
>>
>> I think I see a couple of potential issues, and I'm hoping you can clear
>> a
>> couple of things up.
>>
>> The first is named instruments.  I understand you are most likely aware
>> of
>> the problems with named instruments, though it can't hurt to mention it. 
>> If
>> an instrument is named, then users can no longer use a string as a
>> pfield.
>> This is a problem if one needs to use a pfield to specify the name of an
>> audio file in an i-event.  Signal flow graph or not, Csound would greatly
>> benefit from having this restriction removed, for a variety of reasons.
>>
>> Another is the re-use of instruments/code.  If users needed to use two
>> instruments that were exactly the same in a graph, would they need to
>> copy
>> and paste that instrument?  Or is there a mechanism/opcode/way to
>> auto-duplicate and re-use the same code base?  For example, if I wanted
>> to
>> use two identical reverbs in a signalflowgraph, would I have to
>> explicitly
>> write two copies like this?
>>
>>     signalflowgraph
>>
>>     instr "myVerb"
>>         ; code
>>     endin
>>
>>     instr "myVerb2"
>>         ; duplicate code from "myVerb"
>>     endin
>>
>> Best,
>> Jake
>>
>>
>> Michael Gogins-2 wrote:
>>>
>>> I have made some progress in implementing these opcodes. I have decided
>>> that
>>> for now the proposed pmap opcode is not feasible; at least, the concept
>>> is
>>>
>>> not feasible purely as an opcode.
>>>
>>> I believe all the other features can be implemented using only opcodes.
>>> This
>>> work has caused me to refine the specification somewhat, see below.
>>>
>>> Regards,
>>> Mike
>>>
>>> /**
>>>  * T H E   S I G N A L   F L O W   G R A P H
>>>  * F A M I L Y   O F   O P C O D E S
>>>  *
>>>  * Michael Gogins
>>>  *
>>>  * These opcodes enable the declaration
>>>  * of signal flow graphs (AKA asynchronous data flow graphs)
>>>  * in Csound orchestras. Signals flow
>>>  * from the outlets of source instruments
>>>  * to the inlets of sink instruments.
>>>  * Signals may be k-rate, a-rate, or f-rate.
>>>  * Any number of outlets may be connected
>>>  * to any number of inlets. When a new instance
>>>  * of an instrument is instantiated
>>>  * during performance, the declared connections also
>>>  * are automatically instantiated.
>>>  *
>>>  * Signal flow graphs simplify the construction of complex mixers,
>>>  * signal processing chains, and the like. They also simplify the
>>>  * re-use of instrument definitions and even entire orchestras,
>>>  * which can simply be #included and then "plugged in"
>>>  * to existing orchestras.
>>>  *
>>>  * Instruments must be named, and each source instrument
>>>  * must be defined in the orchestra before any of its sinks.
>>>  * The reason instruments must be named is so that
>>>  * outlets and inlets in any higher-level orchestra can
>>>  * be connected to inlets and outlets in any lower-level
>>>  * #included orchestra.
>>>  *
>>>  * O P C O D E S
>>>  *
>>>  * signalflowgraph
>>>  *
>>>  * Initializes the signal flow graph; must be declared once
>>>  * and only once in the top-level orchestra,
>>>  * before any of the other signal flow graph opcodes.
>>>  *
>>>  * outleta Sname, asignal
>>>  * outletk Sname, ksignal
>>>  * outletf Sname, fsignal
>>>  *
>>>  * Outlets send a, k, or f-rate signals out from an instrument.
>>>  *
>>>  * The name of the outlet is implicitly qualified by the instrument
>>> name,
>>>  * so it is valid to use the same outlet name in more than one
>>> instrument
>>>  * (but not to use the same outlet name twice in the same instrument).
>>>  *
>>>  * asignal inleta Sname
>>>  * ksignal inletk Sname
>>>  * fsignal inletf Sname
>>>  *
>>>  * Inlets receive a, k, or f-rate signals from outlets in other
>>> instruments.
>>>  * The signals from all the source outlet instances are summed
>>>  * in each sink inlet instance.
>>>  *
>>>  * The name of the inlet is implicitly qualified by the instrument name,
>>>  * so it is valid to use the same inlet name in more than one instrument
>>>  * (but not to use the same inlet name twice in the same instrument).
>>>  *
>>>  * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2,
>>> Sink1,
>>>
>>> Sinlet2] ...]]
>>>  *
>>>  * The connect opcode, valid only in orchestra headers, sends the
>>> signals
>>>  * from the indicated outlets in all instances of the indicated source
>>>  * instrument to the indicated inlets in all instances of the indicated
>>> sink
>>>  * instrument.
>>>  *
>>>  * alwayson Sinstrumentname [p4, ..., pn]
>>>  *
>>>  * Activates the indicated instrument in the orchestra header,
>>>  * without need for an i statement. Instruments must be
>>>  * activated in the same order as they are defined.
>>>  *
>>>  * The alwayson opcode is designed to simplify
>>>  * the definition of re-usable orchestras with
>>>  * signal processing or effects chains and networks.
>>>  *
>>>  * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is
>>> -1.
>>>  * The optional pfields are sent to the instrument following p3.
>>>  *
>>>  * ifno ftgenonce isize, igen [, iarga, iargb, ...]
>>>  *
>>>  * Enables the creation of function tables
>>>  * entirely inside instrument definitions,
>>>  * without any duplication of data.
>>>  *
>>>  * The ftgenonce opcode is designed to simplify
>>>  * writing instrument definitions that can be
>>>  * re-used in different orchestras simply by #including them
>>>  * and plugging them into some output instrument.
>>>  * There is no need to define function tables
>>>  * either in the score, or in the orchestra header.
>>>  *
>>>  * The ftgenonce opcode is similar to ftgentmp,
>>>  * except that function tables are neither
>>>  * duplicated nor deleted. Instead, all of the arguments
>>>  * to the opcode are concatenated to form the key
>>>  * to a lookup table that points to the function
>>>  * table structure. Every request to ftgenonce
>>>  * with the same arguments receives the same
>>>  * instance of the function table data.
>>>  * Every change in the value of any ftgenonce argument
>>>  * causes the creation of a new function table.
>>>  */
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25477811.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

It's OK if a file contains unused instruments, their templates will be
compiled and then things will stop. Only used instruments get actual
instantiations. I do not regard this as a serious problem because most
of the templates do not take very much memory, a few hundred bytes or
a few thousand at the most, compared to hundreds of megabytes
available.

I will look more closely at your stuff....

Regards,
Mike

On 9/16/09, Jacob Joaquin  wrote:
>
> I've upgraded my py script to support importing classes from from external
> files, and have created an example.  Here are the two source files:
>
> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/importing.csd
> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/fx_library.csd
>
>
> When importing.csd is preprocessed with template.py, it selectively imports
> classes from fx_library.csd, and creates a new csd.  From this, I created
> temp.csd, which csound can run:
>
> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/temp.csd
>
>
> Here is the complete zip, with template.py:
> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/ImportClasses.zip
>
>
> I believe #include will only take us so far in terms of creating shareable
> instruments, as there are some obvious limitations.  For example, #include
> includes the entire file.  If there was a mechanism that could selectively
> include instruments from external files, then that would really open up
> instrument sharing.  A composition would also be an instrument library.
>
> And I also implemented a version of alwayson.  Very useful!
>
> Best,
> Jake
>
>
>
>
> Michael Gogins-2 wrote:
>>
>> Thanks for your very useful comments on my specification.
>>
>> About named instruments, I was not aware of this limitation. It is
>> serious. I don't know what to do about it. I will see how easy it is
>> to remove this awkward limitation in the Csound engine.
>>
>> About duplicate instances of the same instrument, this happens
>> automatically for regular instruments that allocate new instances for
>> score events. But you are correct that my specification does not allow
>> for re-using the same instrument definition under a different name.
>>
>> I don't know how serious this is. I don't know what to do about it.
>> But I am thinking about it! The best I can do right now is declare the
>> body of the instrument, without instr or endin, in an #include file
>> and do this:
>>
>> instr "reverb1"
>> #include "reverb_body.orc"
>> endin
>>
>> instr "reverb2"
>> #include "reverb_boxy.orc"
>> endin
>>
>> This is a hack, and I hope we can do better.
>>
>> The situation is complicated by efforts to get the parser working well
>> enough to be the default. I am not about to make any changes that
>> might break something.
>>
>> One thing I will certainly do is see if Csound exposes enough stuff so
>> that that opcodes can monkey with instrument templates. I have no idea
>> if this even practical right now, and I kind of doubt it. Still, it
>> would be nice. Then an opcode could find a template, make a copy of it
>> and rename it, and insert it in the chain.
>>
>> Obviously, this would make an instrument template into a class and the
>> new template a new instance of that class, although it's not enough to
>> support inheritance.
>>
>> Thanks again,
>>
>> Mike
>>
>> On 9/16/09, Jacob Joaquin  wrote:
>>>
>>> I've spent some time reading and re-reading your spec.  Very impressed
>>> with
>>> it, as it covers much of the ground I was hoping a new patching system
>>> would
>>> have.  In some cases, more.
>>>
>>> I think I see a couple of potential issues, and I'm hoping you can clear
>>> a
>>> couple of things up.
>>>
>>> The first is named instruments.  I understand you are most likely aware
>>> of
>>> the problems with named instruments, though it can't hurt to mention it.
>>> If
>>> an instrument is named, then users can no longer use a string as a
>>> pfield.
>>> This is a problem if one needs to use a pfield to specify the name of an
>>> audio file in an i-event.  Signal flow graph or not, Csound would greatly
>>> benefit from having this restriction removed, for a variety of reasons.
>>>
>>> Another is the re-use of instruments/code.  If users needed to use two
>>> instruments that were exactly the same in a graph, would they need to
>>> copy
>>> and paste that instrument?  Or is there a mechanism/opcode/way to
>>> auto-duplicate and re-use the same code base?  For example, if I wanted
>>> to
>>> use two identical reverbs in a signalflowgraph, would I have to
>>> explicitly
>>> write two copies like this?
>>>
>>>     signalflowgraph
>>>
>>>     instr "myVerb"
>>>         ; code
>>>     endin
>>>
>>>     instr "myVerb2"
>>>         ; duplicate code from "myVerb"
>>>     endin
>>>
>>> Best,
>>> Jake
>>>
>>>
>>> Michael Gogins-2 wrote:
>>>>
>>>> I have made some progress in implementing these opcodes. I have decided
>>>> that
>>>> for now the proposed pmap opcode is not feasible; at least, the concept
>>>> is
>>>>
>>>> not feasible purely as an opcode.
>>>>
>>>> I believe all the other features can be implemented using only opcodes.
>>>> This
>>>> work has caused me to refine the specification somewhat, see below.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> /**
>>>>  * T H E   S I G N A L   F L O W   G R A P H
>>>>  * F A M I L Y   O F   O P C O D E S
>>>>  *
>>>>  * Michael Gogins
>>>>  *
>>>>  * These opcodes enable the declaration
>>>>  * of signal flow graphs (AKA asynchronous data flow graphs)
>>>>  * in Csound orchestras. Signals flow
>>>>  * from the outlets of source instruments
>>>>  * to the inlets of sink instruments.
>>>>  * Signals may be k-rate, a-rate, or f-rate.
>>>>  * Any number of outlets may be connected
>>>>  * to any number of inlets. When a new instance
>>>>  * of an instrument is instantiated
>>>>  * during performance, the declared connections also
>>>>  * are automatically instantiated.
>>>>  *
>>>>  * Signal flow graphs simplify the construction of complex mixers,
>>>>  * signal processing chains, and the like. They also simplify the
>>>>  * re-use of instrument definitions and even entire orchestras,
>>>>  * which can simply be #included and then "plugged in"
>>>>  * to existing orchestras.
>>>>  *
>>>>  * Instruments must be named, and each source instrument
>>>>  * must be defined in the orchestra before any of its sinks.
>>>>  * The reason instruments must be named is so that
>>>>  * outlets and inlets in any higher-level orchestra can
>>>>  * be connected to inlets and outlets in any lower-level
>>>>  * #included orchestra.
>>>>  *
>>>>  * O P C O D E S
>>>>  *
>>>>  * signalflowgraph
>>>>  *
>>>>  * Initializes the signal flow graph; must be declared once
>>>>  * and only once in the top-level orchestra,
>>>>  * before any of the other signal flow graph opcodes.
>>>>  *
>>>>  * outleta Sname, asignal
>>>>  * outletk Sname, ksignal
>>>>  * outletf Sname, fsignal
>>>>  *
>>>>  * Outlets send a, k, or f-rate signals out from an instrument.
>>>>  *
>>>>  * The name of the outlet is implicitly qualified by the instrument
>>>> name,
>>>>  * so it is valid to use the same outlet name in more than one
>>>> instrument
>>>>  * (but not to use the same outlet name twice in the same instrument).
>>>>  *
>>>>  * asignal inleta Sname
>>>>  * ksignal inletk Sname
>>>>  * fsignal inletf Sname
>>>>  *
>>>>  * Inlets receive a, k, or f-rate signals from outlets in other
>>>> instruments.
>>>>  * The signals from all the source outlet instances are summed
>>>>  * in each sink inlet instance.
>>>>  *
>>>>  * The name of the inlet is implicitly qualified by the instrument name,
>>>>  * so it is valid to use the same inlet name in more than one instrument
>>>>  * (but not to use the same inlet name twice in the same instrument).
>>>>  *
>>>>  * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2,
>>>> Sink1,
>>>>
>>>> Sinlet2] ...]]
>>>>  *
>>>>  * The connect opcode, valid only in orchestra headers, sends the
>>>> signals
>>>>  * from the indicated outlets in all instances of the indicated source
>>>>  * instrument to the indicated inlets in all instances of the indicated
>>>> sink
>>>>  * instrument.
>>>>  *
>>>>  * alwayson Sinstrumentname [p4, ..., pn]
>>>>  *
>>>>  * Activates the indicated instrument in the orchestra header,
>>>>  * without need for an i statement. Instruments must be
>>>>  * activated in the same order as they are defined.
>>>>  *
>>>>  * The alwayson opcode is designed to simplify
>>>>  * the definition of re-usable orchestras with
>>>>  * signal processing or effects chains and networks.
>>>>  *
>>>>  * When the instrument is activated, p1 is the insno, p2 is 0, and p3 is
>>>> -1.
>>>>  * The optional pfields are sent to the instrument following p3.
>>>>  *
>>>>  * ifno ftgenonce isize, igen [, iarga, iargb, ...]
>>>>  *
>>>>  * Enables the creation of function tables
>>>>  * entirely inside instrument definitions,
>>>>  * without any duplication of data.
>>>>  *
>>>>  * The ftgenonce opcode is designed to simplify
>>>>  * writing instrument definitions that can be
>>>>  * re-used in different orchestras simply by #including them
>>>>  * and plugging them into some output instrument.
>>>>  * There is no need to define function tables
>>>>  * either in the score, or in the orchestra header.
>>>>  *
>>>>  * The ftgenonce opcode is similar to ftgentmp,
>>>>  * except that function tables are neither
>>>>  * duplicated nor deleted. Instead, all of the arguments
>>>>  * to the opcode are concatenated to form the key
>>>>  * to a lookup table that points to the function
>>>>  * table structure. Every request to ftgenonce
>>>>  * with the same arguments receives the same
>>>>  * instance of the function table data.
>>>>  * Every change in the value of any ftgenonce argument
>>>>  * causes the creation of a new function table.
>>>>  */
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25477811.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Plug-and-Play-Instruments-and-Orchestras-%28Signal-Flow-Graphs%29-tp25464589p25480154.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

Jacob Joaquin wrote:
> I believe #include will only take us so far in terms of creating shareable
> instruments, as there are some obvious limitations.  For example, #include
> includes the entire file.  If there was a mechanism that could selectively
> include instruments from external files, then that would really open up
> instrument sharing.  A composition would also be an instrument library.

We could solve that easily by changing the way we work, namely by 
putting every instrument in a single file, and include the ones in our 
composition that we need, without writing an instrument in the 
composition itself. But I like the import syntax more, it allows you to 
put instruments that somehow belong together in a single file. Although 
you could just as well organize them in folders, I think it is easier to 
work with a smaller number of files, flipping from file to file in an 
editor is annoying.

It would be really great if you could  do this, Michael. The  
limitation of just using one string is really awkward, and I am  
driving at this wall frequently while working with Csound.
Particulary when writing UDOs one has to do ugly tricks (strget or  
something like this) to find a way of doing simple things. An UDO  
should be able to take and to return more than one string.
So one beer at least if there could be solution ...

	joachim


Am 16.09.2009 um 20:55 schrieb Michael Gogins:

> I will see how easy it is
> to remove this awkward limitation in the Csound engine.



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

joachim heintz wrote:
> It would be really great if you could  do this, Michael. The limitation 
> of just using one string is really awkward, and I am driving at this 
> wall frequently while working with Csound.
> Particulary when writing UDOs one has to do ugly tricks (strget or 
> something like this) to find a way of doing simple things. An UDO should 
> be able to take and to return more than one string.
> So one beer at least if there could be solution ...
> 
>     joachim
> 
> 
> Am 16.09.2009 um 20:55 schrieb Michael Gogins:
> 
>> I will see how easy it is
>> to remove this awkward limitation in the Csound engine.
> 

I recall John Fitch looking closely at this very problem some while ago 
and finding it to have deep implications for the code, i.e. not a 
trivial problem. Maybe the new parser is part of the solution. If not 
already home he should be any day now, might be worth looking at it 
together so you don't expend time (re)ploughing the same ground.

Richard Dobson



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

#include does have other issues we need to be aware of.

With #include, the execution order of instruments in an external file are
fixed.  An import system could allow instruments to be arranged as they are
imported.  This particular problem might not be an issue if an instrument
graph built using signalflowgraph is determined by connections.  Or if
instruments definitions are imported from a class/template system, and then
created.

Then there is the namespace issue.  #include requires that instrs in two or
more included files have unique names to work.  There will be cases where
someone is building an orchestra from two or more files that have
overlapping names.  An import system would be able to avert this.

    ; Both file1.csd and file2.csd have an instr named "Foo"
    import "Foo" from "./file1.csd"
    import "Foo" from "./file2.csd" as "Foo_2"

    
While I'm on the subject of namespaces.  I'm intrigued by your suggestion of
qualifying buss names with instrument names.  This concept might be usefully
applied to other areas of Csound.

Best,
Jake


Michael Gogins-2 wrote:
> 
> It's OK if a file contains unused instruments, their templates will be
> compiled and then things will stop. Only used instruments get actual
> instantiations. I do not regard this as a serious problem because most
> of the templates do not take very much memory, a few hundred bytes or
> a few thousand at the most, compared to hundreds of megabytes
> available.
> 
> I will look more closely at your stuff....
> 
> Regards,
> Mike
> 
> On 9/16/09, Jacob Joaquin  wrote:
>>
>> I've upgraded my py script to support importing classes from from
>> external
>> files, and have created an example.  Here are the two source files:
>>
>> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/importing.csd
>> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/fx_library.csd
>>
>>
>> When importing.csd is preprocessed with template.py, it selectively
>> imports
>> classes from fx_library.csd, and creates a new csd.  From this, I created
>> temp.csd, which csound can run:
>>
>> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/temp.csd
>>
>>
>> Here is the complete zip, with template.py:
>> http://www.thumbuki.com/csound/files/mailinglist/ImportClasses/ImportClasses.zip
>>
>>
>> I believe #include will only take us so far in terms of creating
>> shareable
>> instruments, as there are some obvious limitations.  For example,
>> #include
>> includes the entire file.  If there was a mechanism that could
>> selectively
>> include instruments from external files, then that would really open up
>> instrument sharing.  A composition would also be an instrument library.
>>
>> And I also implemented a version of alwayson.  Very useful!
>>
>> Best,
>> Jake
>>
>>
>>
>>
>> Michael Gogins-2 wrote:
>>>
>>> Thanks for your very useful comments on my specification.
>>>
>>> About named instruments, I was not aware of this limitation. It is
>>> serious. I don't know what to do about it. I will see how easy it is
>>> to remove this awkward limitation in the Csound engine.
>>>
>>> About duplicate instances of the same instrument, this happens
>>> automatically for regular instruments that allocate new instances for
>>> score events. But you are correct that my specification does not allow
>>> for re-using the same instrument definition under a different name.
>>>
>>> I don't know how serious this is. I don't know what to do about it.
>>> But I am thinking about it! The best I can do right now is declare the
>>> body of the instrument, without instr or endin, in an #include file
>>> and do this:
>>>
>>> instr "reverb1"
>>> #include "reverb_body.orc"
>>> endin
>>>
>>> instr "reverb2"
>>> #include "reverb_boxy.orc"
>>> endin
>>>
>>> This is a hack, and I hope we can do better.
>>>
>>> The situation is complicated by efforts to get the parser working well
>>> enough to be the default. I am not about to make any changes that
>>> might break something.
>>>
>>> One thing I will certainly do is see if Csound exposes enough stuff so
>>> that that opcodes can monkey with instrument templates. I have no idea
>>> if this even practical right now, and I kind of doubt it. Still, it
>>> would be nice. Then an opcode could find a template, make a copy of it
>>> and rename it, and insert it in the chain.
>>>
>>> Obviously, this would make an instrument template into a class and the
>>> new template a new instance of that class, although it's not enough to
>>> support inheritance.
>>>
>>> Thanks again,
>>>
>>> Mike
>