Csound never crashed with me because of signal routing.

----- Original Message ----- 
From: "Michael Gogins" 
To: 
Sent: Friday, January 18, 2008 8:13 PM
Subject: [Csnd] Re: Re: Re: python language proxy


> 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"
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"