One other thing to note about the newer syntax is that another avenue
to explore is the explicit declaration of variables, such as:

declare inst0:Instr

inst0 nstance "MyInstr", 0, -1, 440, -12

or some syntax like this.  I'm not a huge fan of pre-declaring
variables for Csound, but it's an option I thought I'd mention.

On Wed, Nov 25, 2015 at 12:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
> The issue with this is that Csound is a statically-typed language and
> the old syntax requires type names be one letter long.  In the nstance
> example, inst0 would be analyzed as a variable with name "inst0" and
> type "I".  The explicitly-typed version would have a variable name
> "inst0" with a type of "Instr".  You should be able to do:
>
> inst0:Instr nstance "MyInstr", 0, -1, 440, -12
>
> but we would still need a way to type the inst0 variable as Instr.
>
> In a future Csound, we would have type inference and the type of inst0
> would be determined though its usage. In that case, we could write:
>
> inst0 = MyInstr(0, -1, 440, -12)
>
> and the compiler would determine for us that inst0 is of type Instr,
> due to the return type of MyInstr().  Type inference has well-known
> models (i.e., extended Hindley-Milner) that we could implement.  The
> colon syntax is an evolutionary step to get there that allows us to
> start defining and using data types with names longer than one letter.
>
> As Csound continues to evolve, I think we will see the language
> growing, but it should not ever break older code.  However, some
> language features and system ideas require a newer syntax that can not
> work with the older opcode-call syntax. I'd just note that users won't
> lose anything by continuing to use older syntax styles, they just
> might not be able to use some newer features.
>
> On Wed, Nov 25, 2015 at 5:02 AM, thorin kerr <thorin.kerr@gmail.com> wrote:
>> Just a quick question on instrument instantiation. I know colons have been
>> introduced with the functional syntax, but they still seem a little
>> un-csoundy to me.
>> Couldn't an existing opcode like nstance be modified to be used like this?
>> So instead of
>> inst0:Instr = MyInstr(0, -1, 440, -12)
>>
>> you could use
>>
>> inst0 nstance "MyInstr" 0, -1, 440, -12
>>
>> Thorin
>>
>>
>>
>> On Tue, Nov 24, 2015 at 1:43 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>>
>>> Hi All,
>>>
>>> I'm posting this to the user list to solicit feedback.  I was talking
>>> with Victor today over coffee and we were reviewing what's done so far
>>> for Csound 7 and some new things we might consider to include for the
>>> release. One idea that came up today was very interesting that we
>>> thought would be a major addition to the system.
>>>
>>> One of the issues that has been raised numerous times over the years
>>> is the issue of instrument processing order and modifying that order.
>>> The problem is that the existing processing model has been in place
>>> for many years, is well known and easy to understand, and is somewhat
>>> at odds with dynamic ordering.
>>>
>>> In discussing it, we came up with the idea to create a new, separate
>>> processing graph.  The existing system orders instances by instrument
>>> number and is really keyed to the instrument definition, not the
>>> instrument instance.  We can see the existing system as a fixed tree
>>> where instrument definitions create a fixed node where instances of
>>> that instrument are appended to for performance. It would look
>>> something like this:
>>>
>>> ROOT
>>> |-INSTR 1
>>>   |--instances
>>> |-INSTR 2
>>>   |--instances
>>>
>>> The existing system has an almost 30 year old practice now associated
>>> with it for ordering of computation.  It is simple, if inflexible, but
>>> it is easy to reason about. It is also tied heavily into the score and
>>> event processing system. By this, I mean that "i" events can be
>>> defined as "instantiate instrument x, and also attach to processing
>>> graph at node INSTR x".
>>>
>>> Instead of having aspects of ordering that is tied to the instrument
>>> definition, the proposal is to create a new processing graph that only
>>> deals with concrete instrument instances.  This system would be an
>>> additional system to use and would not change the existing system; the
>>> existing practices and historical works retain their meaning and
>>> continue to operate as is.
>>>
>>> In the new system, the user would work with the graph entirely within
>>> orchestra code.  Users would create instances of instruments and
>>> explicitly attach them to target nodes.  A global root node would be
>>> available for an engine; new nodes can be created to group instrument
>>> instances together and allow users to specify ordering.
>>>
>>> An example of this might look like this:
>>>
>>> instr MyInstr
>>> ...
>>> endin
>>>
>>> ;; create instance of MyInstr, starting now, indefinite duration, etc.
>>> inst0:Instr = MyInstr(0, -1, 440, -12)
>>> inst1:Instr = MyInstr(0, -1, 880, -12)
>>>
>>> append_to_node(ROOT_NODE, inst1)
>>> append_to_node(ROOT_NODE, inst0)
>>>
>>> In the above, inst0 and inst1 are defined as variables of type Instr
>>> (using new CS7 syntax).  append_to_node adds the instances to the
>>> globally available ROOT_NODE.
>>>
>>> Another example would be:
>>>
>>> instrNode:Node = Node()
>>>
>>> add_to_node(ROOT_NODE, instrNode)
>>> add_to_node(instrNode, inst0)
>>> add_to_node(instrNode, inst1)
>>>
>>> The system would initially look a lot like SuperCollider's node system
>>> and have the same qualities of using nodes to determine ordering, but
>>> not express dependency between node items. User's would be required to
>>> deal with communications between instrument instances, such as using a
>>> global array or bus system, as one would in SC3.
>>>
>>> Also, note that the above revives the notion of instrument as opcode
>>> that was explored by Matt Ingalls with subinstruments. We would have
>>> to change a little bit of what happens: defining a named instrument
>>> would automatically generate an opcode with the name as opname, then
>>> uses arguments with p2 and p3 as arg 1 and 2, and so on.
>>>
>>> Some additional notes:
>>>
>>> 1. User can modify order of instr instances.  This would be done using
>>> opcodes such as remove_from_node(node, instr), insert_into_node(node,
>>> instr, index).  As this is using actual instances and has nothing to
>>> do with instr definitions, the user is in complete control over
>>> ordering (and has the complete responsibility as well).
>>>
>>> 2. To communicate directly to an instrument instance, local channels
>>> may be used.  This would involved overloading chnget and chnset to
>>> take in Instr instances, such as:
>>>
>>> chnset inst0, "cutoff", k1  ;; used outside an instrument instance
>>> chnget this, "cutoff"  ;; used within an instrument instance
>>>
>>> Using channels allows a good correlation with the existing global
>>> channel system.  This should also be fairly easy to then tie into the
>>> API for exposing sending/getting values to an instance of an
>>> instrument.
>>>
>>> 3. Victor and I also spoke about attaching opcodes directly to the new
>>> graph.  (This tied into conversations about opcodes as values we had.)
>>> There are complications here and needs some further exploration.
>>>
>>> 4. The new graph would not work with the existing parallel processing
>>> implementation.  Exploring something like Supernova in SC3 is a
>>> possibility, as is modifying the existing system to analyse based on
>>> instrument instances rather than definitions.
>>>
>>> 5. This work would be best to implement in Csound 7 due to the use of
>>> multi-character type names.  The new types and the system could
>>> technically be written in CS6, but then we'd have to use
>>> single-character type names to define Nodes and Instr instances.
>>> Using the longer type names seems more appropriate to CS7.
>>>
>>> 6. The existing system would not be modified, and the event/score
>>> system would not change. However, this does not mean one wouldn't be
>>> able to use events to work with the new graph. For example, one could
>>> write:
>>>
>>> myNode:Node = Node()
>>> ...
>>>
>>> instr NewGraph
>>>   instr:Instr = MyInstr(.,.,.,.)
>>>   add_to_node(myNode, instr)
>>> endin
>>>
>>> ...
>>>
>>> i "NewGraph" 0 2
>>> i "NewGraph" 2 2
>>>
>>> 7. From an application developer perspective, one would be able to do
>>> things like create mixers with effects and dynamically modify the
>>> effects chain without losing any state of existing effects.
>>>
>>>
>>> This is the basic proposal for the new processing graph. It should be
>>> considered a starting point.  The implementation will require
>>> community feedback to understand what are all of the features we would
>>> want out of the system as well as discover potential issues.
>>>
>>> Thanks!
>>> steven
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here