I am sorry, but although I fully agree with the goal, I do not agree with 
any of the suggested implementations.

I think we should make strenuous efforts to achieve our goal, which I think 
is quite important, without adding any additional layers to a Csound 
installation.

I would prefer first an implementation that can be achieved using only new 
opcodes, then an implementation that can be achieved using changes in the 
Csound orchestra language, and only failing that addition of templates, 
preprocessors, etc.

I will give more thought as to whether the ideas propounded so far can be 
implemented purely using new opcodes. The inlet and outlets opcodes already 
implemented by me are NOT sufficient for this task, but I think that they 
can be modified to do the job.

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.

The ftgenonce opcode that I suggested should be easy to implement for 
efficiently containing function table definitions within instrument 
definitions, so the oustanding problems as I see them are:

(1) Define inlet and outlet opcodes that do not pre-define connections.

inlet "name", xvariable

outlet "name", xvariable

(2) Define a global opcode that defines connections from outlets to inlets, 
including outlets and inlets in #included files (here inso can be a name or 
a number).

connect insno outlets "name1", "name2" to inlets inso "name3", "name4"

(3) Define static instruments, i.e. that do not require an i statement to 
active. This probably can be done using an option in the new connect opcode, 
or perhaps with separate new "static" or "activate" opcode.

static inso

(4) Global orchestra inlets and outlets, so an instrument or signal 
processor can be defined in a completely self-contained way, ready to plug 
into other orchestras. This would require some change to Csound internals, I 
think. But also I do not think it necessary in order to achieve a workable 
implementation of our goal.

orcname "myorcname"
orcinlet "name", gxvalue
orcoutlet "left", galeft
orcoutlet "right", garight

connect "myinstr" outlets "left", "right" to "myorcname" outlets "left", 
"right"

Then in the master orchestra treat it like any other inlet or outlet except 
that the orcname is used instead of inso.

instr 1
...
outlets "left", aleft, "right", aright
endin

#include "myorc.csd"

connect 1 outlets "left", "right" to "myorcname" inlets "left", "right"

I should be able to flesh these ideas out more completely in the next day or 
so.

Regards,
Mike

----- Original Message ----- 
From: "Stéphane Rollandin" 
To: 
Sent: Sunday, September 13, 2009 5:53 PM
Subject: [Csnd] Re: Re: True Plug and Play Instruments with Templates


> Let me summarize what I understand:
>
> You propose here a meta syntax to be processed by an external engine in 
> order to be converted into a plain CSD. If this is accepted as a standard, 
> then Csound front-ends implementors would be responsible for providing the 
> external engine. You would provide Python script, I would provide Emacs 
> Lisp code in Csound-X, etc. Is it right ?
>
> I see no problem with this approach, other than defining a comprehensive 
> standard agreed upon by everybody. If such a standard (doomed to become 
> over time an actual language IMO, probably much more complex than your 
> current draft) is indeed defined, I would be pleased to extend Csound-X so 
> that it gets supported.
>
> Or should the processing be done by a Csound binary utility delivered as 
> part of the Csound distribution ?
>
> What do others think ?
>
>
> Stef
>
>
>
>
> 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"

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