Plug and Play Instruments and Orchestras (Signal Flow Graphs)

[Michael Gogins-2]

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.
 */



------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

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 <jacobjoaquin@...> 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@... 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@... 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@...
https://lists.sourceforge.net/lists/listinfo/csound-devel