Copying the development list on this.

I have  begun to implement the following as new opcodes (and changing my new 
inlet/outlet opcodes to match this). I think the basics are all here, and 
that it can be implemented fairly easily as a set of C++ opcodes in one 
file. I will implement them and then see how usable this scheme is, 
including #included orcs. I am sure there are things, and implementation 
problems, I haven't yet thought of....

Regards,
Mike

/**
 * These opcodes enable the declaration of a signal flow graph
 * that directly connects instruments in a Csound orchestra
 * using k-rate, a-rate, and f-rate signal flows,
 * from the outlets of source instruments to the inlets of sink instruments.
 *
 * Instruments must be named, and they must be defined in the orchestra
 * in order of depth-first traversal of the signal flow graph, i.e.,
 * each source must execute before any of its sinks. The reason instruments
 * must be named is so that outlets and inlets in any orchestra can
 * be connected to inlets and outlets in any #included orchestra. This
 * requirement on order of definition extends to #included orchestras.
 *
 * The instrument name is implicitly attached to the inlet or outlet name.
 *
 * outleta Sname, asignal
 * outletk Sname, ksignal
 * outletf Sname, fsignal
 *
 * Inlets receive the outlets that have been connected to them using the 
"connect" opcode.
 * If multiple instances of an instrument's outlets are connected to a 
single inlet,
 * the multiple outlets are summed in the inlet variable.
 *
 * asignal inleta Sname
 * ksignal inletk Sname
 * fsignal inletf Sname
 *
 * The connect opcode, valid only at the global level, instructs the innards
 * of the various inlet opcodes which outlets they should receive.
 *
 * connect Source1, Soutlet1, Sink1, Sinlet1 [[, Source2, Soutlet2, Sink1, 
Sinlet2] ...]]
 *
 * The alwayson opcode activates the indicated instrument in the orchestra 
header,
 * without need for an i statement. These statements are stored for 
execution in proper order.
 * p1 is ignored, p2 is ignored and set to 0, and p3 is ignored and set 
to -1.
 *
 * alwayson Sinstrumentname [p1, p2, p3, ..., pn]
 *
 * The ftgenonce opcode is designed to simplify the construction of signal 
flow graphs
 * by simplifying the creation of function tables, without duplication of 
data, entirely
 * within instrument definitions. The opcode is identical 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.
 *
 * ifno ftgenonce ip1, ip2dummy, isize, igen, iarga, iargb, ...
 */

----- Original Message ----- 
From: "Jacob Joaquin" 
To: 
Sent: Sunday, September 13, 2009 7:09 PM
Subject: [Csnd] Re: Re: Re: True Plug and Play Instruments with Templates


>
> My py script, as is, acts as a preprocessor.  Though it does allow
> connections to be named on a global level, in a sense.
>
>    class Foo #outlet
>        a1 oscils 1, 440, 1
>        outleta "#outlet", a1
>    endclass
>
> In the first line, #outlet specifies a generic argument that a user
> specifies when he or she creates an instance of the class.  When Foo is
> created, the user chooses a name, and that name is replaced in the second
> line of the classes body.  So in the following case:
>
>    create 1 from Foo foo_out
>
> An instr is created, with #outlet being substituted with foo_out.
>
>    instr 1
>        a1 oscils 1, 440, 1
>        outleta "foo_out", a1
>    endclass
>
> I can continue creating instrs with different outlet names:
>
>    create 2 from Foo another_connection
>    create 3 from Foo hello_world
>
> These translate to:
>
>    instr 2
>        a1 oscils 1, 440, 1
>        outleta "another_connection", a1
>    endclass
>    instr 3
>        a1 oscils 1, 440, 1
>        outleta "hello_world", a1
>    endclass
>
> The important thing is that the names aren't defined in the class, just a
> placer for where the buss names will eventually go.  Is this the perfect
> implementation?  I doubt it.  Though functionality speaking, it 
> accomplishes
> the goal of having independently defined connections.
>
> In the end, one can make the case that when a class in instantiated, then
> the name becomes hardwired anyways.  If the Csound instrument graph was 
> more
> dynamic during run-time, then my implementation as is would absolutely be
> inadequate.
>
> Best,
> Jake
>
>
>
>
> Michael Gogins-2 wrote:
>>
>> The key requirement, as I see it, is that instruments with some sort of
>> inlets and outlets must be defined INDEPENDENTLY of how instruments are
>> connected. My inlets and outlets don't do this, the connections are
>> specified within the instrument definition. The connections have to be
>> defined at the global level of the orchestra. As far as I can tell Jacob
>> Joaqin's proposal also does not do this.
>>
>
> -- 
> View this message in context: 
> http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25428263.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"