I've been thinking about the "engine" for Csound 6, which is the part
that actually runs the performance once the orchestra and score are
compiled.

Like many signal processing systems, the Csound engine is (more or
less) a data flow graph. Some computer music systems, such as Max, are
explicitly visual data flow programming languages. With Csound, the
data flow graph is more implicit and it is not formally purely a data
flow graph.

As far as I can tell the Csound "engine" is a heterogeneous
synchronous semi-dynamic data flow graph (HSDSFG). It is
"heterogeneous" because the nodes or "actors" of the graph are not low
level machine instructions, but blocks of compiled imperative C code,
that is, opcodes. It is "synchronous" because the number of data
elements on each edge of the graph is fixed and known in advance
(ksmps audio samples or 1 control sample). It is "semi-dynamic"
because, although the topology of the graph is mostly known in
advance, score events, and especially real-time score events, may
cause the insertion of new sub-graphs (new instrument instances) into
the graph while it runs.

Data flow graphs of all kinds have been extensively researched and I
find they provide a good formal framework for thinking about the
issues involved in designing and coding the "engine." In particular,
DFGs provide formal methods for scheduling and evaluating graphs,
especially for concurrent execution, conditional expressions, and
loops, and avoid many of the problems involved in explicitly
programming with threads.

I'm hoping that taking advantage of the research that has been done in
this field could refine and simplify our redesign of the "engine" and
enable us to create one that can perform with optimum use of multiple
threads while avoiding some of the problems of threading. This
research has been widely used by commercial and military DSP
programmers.

The following is a recent review of academic research in data flow
languages and I found it helpful in thinking through some of the
issues: http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf

Anyone interested in learning more about academic research in this
field could start by checking out the following Web sites:

Ptolemy II - http://ptolemy.eecs.berkeley.edu/ptolemyII/

Maryland DSP/CAD - http://www.ece.umd.edu/DSPCAD/home/dspcad.htm

Chess - http://chess.eecs.berkeley.edu/ This one is more about
problems interfacing cybernetic systems across networks and with
physical devices, but that's certainly relevant to Csound as well.

Tentatively, I guess that designing the engine more formally as a
HSDSFG might result in the following sorts of changes:

(1) instruments and opcodes would formally be nodes on the same level
of the DFG. Only the semantic actions in the parser would know the
difference.

(2) The global (orc header) instrument would be on the same level as
the other instruments.

(3) All data values including pfields, arate variables, krate
variables, tables, fsigs, and vectors would be edges in the graph.

(4) In a DFG there are no side effects of evaluation, and in this
sense DFGs are functional programming languages. That means that all
nodes on the same layer of dependency can be scheduled to run in any
order with respect to each other, e.g. from a pool of threads that are
always running. This would not require any mutexes or anything like
that, it would be done purely by building a scheduling matrix for the
graph. There would simply be a barrier at each "layer" of dependency,
i.e. each row in the scheduling matrix. New instrument instances would
simply insert a (possibly large) number of new columns into the same
scheduling matrix without changing the layers or barriers.

(5) There would be a "node and edge" structure and API such that the
compiled graph would be accessible to programmers. This would enable
e.g. composers to write instruments in any language that builds the
correct node and edge structure.

(6) Similarly it would be possible to define different parsers that
would build graphs for the engine using the existing Csound opcodes
and even instrument definitions.

(7) Last but not least, formalising the engine as a HSDSFG would make
it easier to create a true visual patching language for Csound: the
patcher would not generate Csound code as existing patchers do, but
directly create a graph in the engine using any set of Csound opcodes
or plugin opcodes.

Regards,
Mike

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

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

Thanks for the thoughtful insights and links to papers (downloaded and
will read on the train later today).  I think while the language I've
been using has not been as formal in describing the system, I think
we're on the same page (I had referred to things being "tickable",
whether its an opcode, instrument, score timeline, etc.).  Also, John,
Victor, and I were on IRC yesterday chatting about Csound 6 and
discussed a context struct that would be used in instruments,
instances, and global levels to hold settings like ksmps (so that the
hack used for setksmps could be taken out).  Also, we discussed having
output from the out opcodes write to the context, and then pulled and
mixed together by Csound, for the purposes of reducing points of
contention and improving parallelism.

I'm going to read through the articles and hopefully will be able to
discuss in more detail once I get through them.

Thanks!
steven

On Sat, Apr 7, 2012 at 3:14 PM, Michael Gogins  wrote:
> I've been thinking about the "engine" for Csound 6, which is the part
> that actually runs the performance once the orchestra and score are
> compiled.
>
> Like many signal processing systems, the Csound engine is (more or
> less) a data flow graph. Some computer music systems, such as Max, are
> explicitly visual data flow programming languages. With Csound, the
> data flow graph is more implicit and it is not formally purely a data
> flow graph.
>
> As far as I can tell the Csound "engine" is a heterogeneous
> synchronous semi-dynamic data flow graph (HSDSFG). It is
> "heterogeneous" because the nodes or "actors" of the graph are not low
> level machine instructions, but blocks of compiled imperative C code,
> that is, opcodes. It is "synchronous" because the number of data
> elements on each edge of the graph is fixed and known in advance
> (ksmps audio samples or 1 control sample). It is "semi-dynamic"
> because, although the topology of the graph is mostly known in
> advance, score events, and especially real-time score events, may
> cause the insertion of new sub-graphs (new instrument instances) into
> the graph while it runs.
>
> Data flow graphs of all kinds have been extensively researched and I
> find they provide a good formal framework for thinking about the
> issues involved in designing and coding the "engine." In particular,
> DFGs provide formal methods for scheduling and evaluating graphs,
> especially for concurrent execution, conditional expressions, and
> loops, and avoid many of the problems involved in explicitly
> programming with threads.
>
> I'm hoping that taking advantage of the research that has been done in
> this field could refine and simplify our redesign of the "engine" and
> enable us to create one that can perform with optimum use of multiple
> threads while avoiding some of the problems of threading. This
> research has been widely used by commercial and military DSP
> programmers.
>
> The following is a recent review of academic research in data flow
> languages and I found it helpful in thinking through some of the
> issues: http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf
>
> Anyone interested in learning more about academic research in this
> field could start by checking out the following Web sites:
>
> Ptolemy II - http://ptolemy.eecs.berkeley.edu/ptolemyII/
>
> Maryland DSP/CAD - http://www.ece.umd.edu/DSPCAD/home/dspcad.htm
>
> Chess - http://chess.eecs.berkeley.edu/ This one is more about
> problems interfacing cybernetic systems across networks and with
> physical devices, but that's certainly relevant to Csound as well.
>
> Tentatively, I guess that designing the engine more formally as a
> HSDSFG might result in the following sorts of changes:
>
> (1) instruments and opcodes would formally be nodes on the same level
> of the DFG. Only the semantic actions in the parser would know the
> difference.
>
> (2) The global (orc header) instrument would be on the same level as
> the other instruments.
>
> (3) All data values including pfields, arate variables, krate
> variables, tables, fsigs, and vectors would be edges in the graph.
>
> (4) In a DFG there are no side effects of evaluation, and in this
> sense DFGs are functional programming languages. That means that all
> nodes on the same layer of dependency can be scheduled to run in any
> order with respect to each other, e.g. from a pool of threads that are
> always running. This would not require any mutexes or anything like
> that, it would be done purely by building a scheduling matrix for the
> graph. There would simply be a barrier at each "layer" of dependency,
> i.e. each row in the scheduling matrix. New instrument instances would
> simply insert a (possibly large) number of new columns into the same
> scheduling matrix without changing the layers or barriers.
>
> (5) There would be a "node and edge" structure and API such that the
> compiled graph would be accessible to programmers. This would enable
> e.g. composers to write instruments in any language that builds the
> correct node and edge structure.
>
> (6) Similarly it would be possible to define different parsers that
> would build graphs for the engine using the existing Csound opcodes
> and even instrument definitions.
>
> (7) Last but not least, formalising the engine as a HSDSFG would make
> it easier to create a true visual patching language for Csound: the
> patcher would not generate Csound code as existing patchers do, but
> directly create a graph in the engine using any set of Csound opcodes
> or plugin opcodes.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This is a somewhat more recent paper by some of the leading
researchers in this field. A cursory read of this paper shows that it
covers some of the same ground that the ParCS design and code covers.
What it is interesting is that this paper is trying take a formalized
approach to scheduling data flow graphs that balances tradeoffs,
measures how fast nodes run, and accounts for actual threads and
synchronization primitives. I am going to look and see if they have
code that does this stuff.

http://www.ece.umd.edu/DSPCAD/papers/hsu2011x1.pdf

Regards,
Mike

On Sat, Apr 7, 2012 at 11:06 AM, Steven Yi  wrote:
> Hi Michael,
>
> Thanks for the thoughtful insights and links to papers (downloaded and
> will read on the train later today).  I think while the language I've
> been using has not been as formal in describing the system, I think
> we're on the same page (I had referred to things being "tickable",
> whether its an opcode, instrument, score timeline, etc.).  Also, John,
> Victor, and I were on IRC yesterday chatting about Csound 6 and
> discussed a context struct that would be used in instruments,
> instances, and global levels to hold settings like ksmps (so that the
> hack used for setksmps could be taken out).  Also, we discussed having
> output from the out opcodes write to the context, and then pulled and
> mixed together by Csound, for the purposes of reducing points of
> contention and improving parallelism.
>
> I'm going to read through the articles and hopefully will be able to
> discuss in more detail once I get through them.
>
> Thanks!
> steven
>
> On Sat, Apr 7, 2012 at 3:14 PM, Michael Gogins  wrote:
>> I've been thinking about the "engine" for Csound 6, which is the part
>> that actually runs the performance once the orchestra and score are
>> compiled.
>>
>> Like many signal processing systems, the Csound engine is (more or
>> less) a data flow graph. Some computer music systems, such as Max, are
>> explicitly visual data flow programming languages. With Csound, the
>> data flow graph is more implicit and it is not formally purely a data
>> flow graph.
>>
>> As far as I can tell the Csound "engine" is a heterogeneous
>> synchronous semi-dynamic data flow graph (HSDSFG). It is
>> "heterogeneous" because the nodes or "actors" of the graph are not low
>> level machine instructions, but blocks of compiled imperative C code,
>> that is, opcodes. It is "synchronous" because the number of data
>> elements on each edge of the graph is fixed and known in advance
>> (ksmps audio samples or 1 control sample). It is "semi-dynamic"
>> because, although the topology of the graph is mostly known in
>> advance, score events, and especially real-time score events, may
>> cause the insertion of new sub-graphs (new instrument instances) into
>> the graph while it runs.
>>
>> Data flow graphs of all kinds have been extensively researched and I
>> find they provide a good formal framework for thinking about the
>> issues involved in designing and coding the "engine." In particular,
>> DFGs provide formal methods for scheduling and evaluating graphs,
>> especially for concurrent execution, conditional expressions, and
>> loops, and avoid many of the problems involved in explicitly
>> programming with threads.
>>
>> I'm hoping that taking advantage of the research that has been done in
>> this field could refine and simplify our redesign of the "engine" and
>> enable us to create one that can perform with optimum use of multiple
>> threads while avoiding some of the problems of threading. This
>> research has been widely used by commercial and military DSP
>> programmers.
>>
>> The following is a recent review of academic research in data flow
>> languages and I found it helpful in thinking through some of the
>> issues: http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf
>>
>> Anyone interested in learning more about academic research in this
>> field could start by checking out the following Web sites:
>>
>> Ptolemy II - http://ptolemy.eecs.berkeley.edu/ptolemyII/
>>
>> Maryland DSP/CAD - http://www.ece.umd.edu/DSPCAD/home/dspcad.htm
>>
>> Chess - http://chess.eecs.berkeley.edu/ This one is more about
>> problems interfacing cybernetic systems across networks and with
>> physical devices, but that's certainly relevant to Csound as well.
>>
>> Tentatively, I guess that designing the engine more formally as a
>> HSDSFG might result in the following sorts of changes:
>>
>> (1) instruments and opcodes would formally be nodes on the same level
>> of the DFG. Only the semantic actions in the parser would know the
>> difference.
>>
>> (2) The global (orc header) instrument would be on the same level as
>> the other instruments.
>>
>> (3) All data values including pfields, arate variables, krate
>> variables, tables, fsigs, and vectors would be edges in the graph.
>>
>> (4) In a DFG there are no side effects of evaluation, and in this
>> sense DFGs are functional programming languages. That means that all
>> nodes on the same layer of dependency can be scheduled to run in any
>> order with respect to each other, e.g. from a pool of threads that are
>> always running. This would not require any mutexes or anything like
>> that, it would be done purely by building a scheduling matrix for the
>> graph. There would simply be a barrier at each "layer" of dependency,
>> i.e. each row in the scheduling matrix. New instrument instances would
>> simply insert a (possibly large) number of new columns into the same
>> scheduling matrix without changing the layers or barriers.
>>
>> (5) There would be a "node and edge" structure and API such that the
>> compiled graph would be accessible to programmers. This would enable
>> e.g. composers to write instruments in any language that builds the
>> correct node and edge structure.
>>
>> (6) Similarly it would be possible to define different parsers that
>> would build graphs for the engine using the existing Csound opcodes
>> and even instrument definitions.
>>
>> (7) Last but not least, formalising the engine as a HSDSFG would make
>> it easier to create a true visual patching language for Csound: the
>> patcher would not generate Csound code as existing patchers do, but
>> directly create a graph in the engine using any set of Csound opcodes
>> or plugin opcodes.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



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

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net