That reminds me, Csound schedules instruments first in instrument number order, and then in instance order. Signal routing within this order is arbitrary and can lead to problems and crashes.

I suggest it might be better for Csound to extend this scheme with a true data flow graph or DSP graph design. This could not be done now, but perhaps it could be done as part of the parser implementation. It would also make it possible to easily subdivide the orchestra into parts that can run in parallel.

Such a design works like this:

Each unit generator is a subgraph in which input nodes (often called inlets, in our case the parameters of the opcode) are connected to a processing node (in our case the kperiod function). The processing node in turn is connected to output nodes (often called outlets, in our case the return value(s) (or left-hand side of the opcode).

    a1   k1  k2  k3
     |   |   |   |
  +--+---+---+---+--+
  |   \  \  /   /   |
  |     kopadr      |
  |        |        |
  +--------+--------+
           |
          aout

An graph is then created by connecting the output nodes (opcode return values  or outlets) of some opcodes to the input nodes (opcode parameters) of other opcodes, to produce a directed acyclical graph that represents a data flow program. In reality, at 1 ksmps, cycles can be permitted without in practice crippling the linear response of the graph. 

In Csound, this already happens inside instrument definitions. What needs to happen is that should also happen between instrument definitions.

The Csound orchestra language would then be extended to include the notion of explicit connections between instrument definitions, which could be used either instead of, or in addition to, the existing "out" family of opcodes and pfields:

; Note: receives pfields,
;       sends outputs to ga1, ga2 instead of using "outs".

ga1, ga2 instr 1 p1, p2, p3, p4
         endin

; Note: receives ga1, ga2 from instr 1 as well as default pfields, 
;       sends outputs to ga3, ga4.

ga3, ga4 instr 2 p1, p2, p3, ga1, ga2
         endin

It is no longer necessary to define instruments in the correct order. Instead, the finished graph (which is just a list of the connection arcs [e.g. (instr1:out1,instr2:in4)] between the nodes, is traversed breadth first and the finished list of nodes is reversed. This reversed breadth-first list computes every instrument in the orchestra in exactly the correct order. When the nodes in the list are ticked: (1) The output nodes do nothing; (2) the input nodes sum the values of their connected input nodes; and (3) the processing nodes compute their output node(s) from their input node(s). The list is then ticked again to clear all the output nodes.

Polyphony can be implemented by scattering control signal output nodes to N instrument subgraphs and gathering the instrument subgraph output signals using a mixer opcode. This gathering and scattering can be an implicit rule.

Each instrument instance subgraph connected to such a mixer can run in parallel:

               control
                  |
         +--------+----------+  ...  +
         |        |          |       |
        inst[0] inst[1] inst[2] inst[n] 
         |        |          |       |
         +--------+----------+  ...  +
                  |
                mixer
            
Similarly, if the signal flow graph branches in some other way, each of the legs of the independent branches on the same level can run in parallel:

                    m i x e r
                  left     right
                  /         \
                 /           \
                /             \
           left reverb    right reverb
               |               |
              eq 1           eq 2
                 \            /
                  \          /
                   \        /
                    \      /
                    m i x e r

In this case the left reverb-EQ leg can run in parallel with the right reverb-EQ leg (as long as the mixers run before and after).

Furthermore, with such a design, one can dynamically edit the graph while it is running (this is similar to what ChucK does).

There is much more that can be said about this. Conceptually, the score can become an instrument with pfield outputs that connect to instrument pfield inputs. 

Regards,
Mike

-----Original Message-----
>From: Eduardo Moguillansky 
>Sent: Jan 18, 2008 12:52 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Re: Re:  python language proxy
>
>
>jpff@cs.bath.ac.uk wrote:
>>>  is there any way to add instrs/opcodes on the fly? 
>>>     
>>
>> Simple answer; no
>> Complex answer, we really want it but so far noone has had the time
>> to do it.  Stephen Yi and I had a good brain storm about this at Linux
>> Audio Conference last year.  What some space or other......
>>   
>I see. It would also be helpful to envisage a way of defining 
>instruments which is not bound to a certain evaluation order and allow 
>this to be triggered in the score.
>That would make code more flexible.
>
>-- Eduardo
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"