Hi All,

I was drafting some code for a basis of a type system for Csound.
I've pasted it in below for comments.  The idea I had is:

* Generic type system
* csoundAddVariableType used to add new types; by default, CSOUND
initialized with all classic types (i,k,a,f, w, S, etc.)
* new types could have longer names; potentially useful if used with
alternate languages to classic csound orc, or if classic orc modified
to allow optional type (i.e. ivar, myVar:i), then could have
myVar:myDataType
* using this, I think we should be able to support:

data myDataType ivar, kvar, avar

(for user-defined data types)

* variable pools (what I called contexts in prior emails) could be
held in CSOUND struct, as well as in UDO's, UDDT (User-Defined Data
Types), and Instruments.

* generic type system should allow for generic arrays (using types
such as S[], F[], etc.)

* the CS_VAR_POOL would hold pre-allocated memory; allocation of new
instances of instrument would count size of vars in pool, then malloc
one big block; locations in block assigned according to dynamic
counting of sizes of vars in the linked list (removing use of indexes
as variable locations done during compiler); I think this could be
made to be as efficient as the current memory allocation strategy

* INSTRDEF would replace INSTRTXT, using var pool instead of all of
the variable counts

* INSTRDEF could be entry-way for host-defined instrument, where
"struct op * nxtop;" is replaced with a host-function hook


Code draft below.  It's probably a bit naive as I have not really
looked at creating type systems and will be exploring that over the
next week or two.  Comments and suggestions very much appreciated!

steven



/* BEGIN CSOUND TYPE SYSTEM WORK */

    typedef struct cstype {
        char* varTypeName;
        char* varMemberName; /* Used when member of aggregate type */
        char* varDescription;
        cstype* members;
    } CS_TYPE;

    typedef struct csvariable {
        char* varName;
        CS_TYPE* varType;
        void* memblock;
        int refCount;
    } CS_VARIABLE;

    /* Adds a new type to Csound's type table
       Returns if variable type redefined */
    bool csoundAddVariableType(CSOUND* csound,
                               CS_TYPE type,
                               CS_VARIABLE* (*createVariable)(void*
initialData));

    /* Csound Variable Pool - essentially a map
       CSOUND contains one for global memory, InstrDef and UDODef
       contain a pool for local memory
     */

    typedef struct csvarpool {
        CS_VARIABLE* head;
    } CS_VAR_POOL;

    /**
     * This struct is filled out by otran() at orch parse time.
     * It is used as a template for instrument events.
     */
    typedef struct instrdef {
        CS_VAR_POOL variables;
        struct op * nxtop;              /* Linked list of instr opcodes */
        TEXT    t;                      /* Text of instrument (same in nxtop) */
        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
                                         opcodes in instr */
        int16   muted;
        int32   localen;
        int32   opdstot;                /* Total size of opds structs
in instr */
        MYFLT   *psetdata;              /* Used for pset opcode */
        struct insds * instance;        /* Chain of allocated instances of
                                         this instrument */
        struct insds * lst_instance;    /* last allocated instance */
        struct insds * act_instance;    /* Chain of free (inactive) instances */
        /* (pointer to next one is INSDS.nxtact) */
        struct instr2 * nxtinstxt;       /* Next instrument in orch
(num order) */
        int     active;                 /* To count activations for control */
        int     maxalloc;
        MYFLT   cpuload;                /* % load this instrumemnt makes */
        char    *insname;               /* instrument name */
        int     instcnt;                /* Count number of instances ever */
    } INSTRDEF;

/* END CSOUND TYPE SYSTEM WORK */

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

sounds exciting!
looking forward to it. all best -
	joachim

Am 30.05.2012 22:55, schrieb Steven Yi:
> Hi All,
> 
> I was drafting some code for a basis of a type system for Csound.
> I've pasted it in below for comments.  The idea I had is:
> 
> * Generic type system
> * csoundAddVariableType used to add new types; by default, CSOUND
> initialized with all classic types (i,k,a,f, w, S, etc.)
> * new types could have longer names; potentially useful if used with
> alternate languages to classic csound orc, or if classic orc modified
> to allow optional type (i.e. ivar, myVar:i), then could have
> myVar:myDataType
> * using this, I think we should be able to support:
> 
> data myDataType ivar, kvar, avar
> 
> (for user-defined data types)
> 
> * variable pools (what I called contexts in prior emails) could be
> held in CSOUND struct, as well as in UDO's, UDDT (User-Defined Data
> Types), and Instruments.
> 
> * generic type system should allow for generic arrays (using types
> such as S[], F[], etc.)
> 
> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
> instances of instrument would count size of vars in pool, then malloc
> one big block; locations in block assigned according to dynamic
> counting of sizes of vars in the linked list (removing use of indexes
> as variable locations done during compiler); I think this could be
> made to be as efficient as the current memory allocation strategy
> 
> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
> the variable counts
> 
> * INSTRDEF could be entry-way for host-defined instrument, where
> "struct op * nxtop;" is replaced with a host-function hook
> 
> 
> Code draft below.  It's probably a bit naive as I have not really
> looked at creating type systems and will be exploring that over the
> next week or two.  Comments and suggestions very much appreciated!
> 
> steven
> 
> 
> 
> /* BEGIN CSOUND TYPE SYSTEM WORK */
> 
>     typedef struct cstype {
>         char* varTypeName;
>         char* varMemberName; /* Used when member of aggregate type */
>         char* varDescription;
>         cstype* members;
>     } CS_TYPE;
> 
>     typedef struct csvariable {
>         char* varName;
>         CS_TYPE* varType;
>         void* memblock;
>         int refCount;
>     } CS_VARIABLE;
> 
>     /* Adds a new type to Csound's type table
>        Returns if variable type redefined */
>     bool csoundAddVariableType(CSOUND* csound,
>                                CS_TYPE type,
>                                CS_VARIABLE* (*createVariable)(void*
> initialData));
> 
>     /* Csound Variable Pool - essentially a map
>        CSOUND contains one for global memory, InstrDef and UDODef
>        contain a pool for local memory
>      */
> 
>     typedef struct csvarpool {
>         CS_VARIABLE* head;
>     } CS_VAR_POOL;
> 
>     /**
>      * This struct is filled out by otran() at orch parse time.
>      * It is used as a template for instrument events.
>      */
>     typedef struct instrdef {
>         CS_VAR_POOL variables;
>         struct op * nxtop;              /* Linked list of instr opcodes */
>         TEXT    t;                      /* Text of instrument (same in nxtop) */
>         int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>                                          opcodes in instr */
>         int16   muted;
>         int32   localen;
>         int32   opdstot;                /* Total size of opds structs
> in instr */
>         MYFLT   *psetdata;              /* Used for pset opcode */
>         struct insds * instance;        /* Chain of allocated instances of
>                                          this instrument */
>         struct insds * lst_instance;    /* last allocated instance */
>         struct insds * act_instance;    /* Chain of free (inactive) instances */
>         /* (pointer to next one is INSDS.nxtact) */
>         struct instr2 * nxtinstxt;       /* Next instrument in orch
> (num order) */
>         int     active;                 /* To count activations for control */
>         int     maxalloc;
>         MYFLT   cpuload;                /* % load this instrumemnt makes */
>         char    *insname;               /* instrument name */
>         int     instcnt;                /* Count number of instances ever */
>     } INSTRDEF;
> 
> /* END CSOUND TYPE SYSTEM WORK */
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven,

This is a great idea, and something I've wanted for a long time. Some
thoughts below:

On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
> * generic type system should allow for generic arrays (using types
> such as S[], F[], etc.)

How would this notation be handled for user-defined types? Would it
always access the n-th element of the variable? This would be nice.
You could actually also access audio vectors this way.

Would it be good to use a '.' notation, to access elements by name, as
in a struct?

Also, how about allowing instruments as a variable type, so you can
use instruments as classes? Would this make sense, or would it be
better just to design a complete class system from the ground up?

Have a look at my ideas for arrays:
http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays

I think it would also be nice to allow nested types, so you can create
an array and then populate it with any types including arrays.

Cheers,
Andrés

>
> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
> instances of instrument would count size of vars in pool, then malloc
> one big block; locations in block assigned according to dynamic
> counting of sizes of vars in the linked list (removing use of indexes
> as variable locations done during compiler); I think this could be
> made to be as efficient as the current memory allocation strategy
>
> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
> the variable counts
>
> * INSTRDEF could be entry-way for host-defined instrument, where
> "struct op * nxtop;" is replaced with a host-function hook
>
>
> Code draft below.  It's probably a bit naive as I have not really
> looked at creating type systems and will be exploring that over the
> next week or two.  Comments and suggestions very much appreciated!
>
> steven
>
>
>
> /* BEGIN CSOUND TYPE SYSTEM WORK */
>
>    typedef struct cstype {
>        char* varTypeName;
>        char* varMemberName; /* Used when member of aggregate type */
>        char* varDescription;
>        cstype* members;
>    } CS_TYPE;
>
>    typedef struct csvariable {
>        char* varName;
>        CS_TYPE* varType;
>        void* memblock;
>        int refCount;
>    } CS_VARIABLE;
>
>    /* Adds a new type to Csound's type table
>       Returns if variable type redefined */
>    bool csoundAddVariableType(CSOUND* csound,
>                               CS_TYPE type,
>                               CS_VARIABLE* (*createVariable)(void*
> initialData));
>
>    /* Csound Variable Pool - essentially a map
>       CSOUND contains one for global memory, InstrDef and UDODef
>       contain a pool for local memory
>     */
>
>    typedef struct csvarpool {
>        CS_VARIABLE* head;
>    } CS_VAR_POOL;
>
>    /**
>     * This struct is filled out by otran() at orch parse time.
>     * It is used as a template for instrument events.
>     */
>    typedef struct instrdef {
>        CS_VAR_POOL variables;
>        struct op * nxtop;              /* Linked list of instr opcodes */
>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>                                         opcodes in instr */
>        int16   muted;
>        int32   localen;
>        int32   opdstot;                /* Total size of opds structs
> in instr */
>        MYFLT   *psetdata;              /* Used for pset opcode */
>        struct insds * instance;        /* Chain of allocated instances of
>                                         this instrument */
>        struct insds * lst_instance;    /* last allocated instance */
>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>        /* (pointer to next one is INSDS.nxtact) */
>        struct instr2 * nxtinstxt;       /* Next instrument in orch
> (num order) */
>        int     active;                 /* To count activations for control */
>        int     maxalloc;
>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>        char    *insname;               /* instrument name */
>        int     instcnt;                /* Count number of instances ever */
>    } INSTRDEF;
>
> /* END CSOUND TYPE SYSTEM WORK */
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/

I'm not sure this is wise. Permit me to explain my thinking. It's
pretty fundamental.

In the first place, having a type system in a software sound synthesis
language is a really great idea. No argument there.

However, I see a tension, in software sound synthesis systems, between
the requirements for software sound synthesis, usually resulting in
some sort of a data flow graph ("signal flow graph"), and the
requirements for a programming language. The graph is needed not only
so that the system will run fast enough, but also as an organizing
metaphor for signal processing and sound synthesis. To the best of my
knowledge, almost all real world, real time or near real time signal
processing systems, for music or otherwise, use some sort of data flow
graph.

Data flow graphs with sufficient logic are Turing complete, so they
can definitely be made into general purpose programming languages. No
argument there.

The tension arises because the objective of a data flow graph with a
type system is challenging. This goal can be met in two ways: by
adding a type system to a data flow graph, or by embedding a data flow
graph into an existing programming language. There are various
examples of this latter approach. SuperCollider sort of does this,
CLAM, STK, and CSL actually do this (but require the C++ compiler).

Historically, almost all software sound synthesis systems have started
with a data flow graph and then added programming language features to
that. This was done because historically, there were no general
purpose programming languages that could run fast enough for signal
processing without using a static compiler.

That is no longer the case. There are several dynamic language
runtimes that are fast enough for our purposes: LuaJIT, several kinds
of JavaScript, possibly Parrot.

In addition, the use of a static compiler has become more practical.
On modern computers, compile times are short, and packaged compilers
are easily available. A number of scientific computing systems
presuppose that GCC is embedded in the system somewhere, and automate
the build process.

I'm quite certain that implementing a software sound synthesis system
with a rich type system, classes, etc., etc., could be done much more
easily by embedding a data flow graph into an existing language such
as LuaJIT or a canned installation of GCC than by bolting more and
more programming language features onto Csound.

The functionality of Csound could be ported into such a system by
creating a wrapper template for Csound opcodes.

In addition to the back end complexities arising from adding
programming language features to the Csound runtime, there are front
end considerations. The user will be forced to learn a new syntax for
operations that he or she may already be familiar with in other
languages. Why? Plus, people have been complaining about awkward
syntax in the Csound language for ages. These complaints could be
resolved at one fell swoop by embedding the Csound data flow graph and
opcodes into an existing, powerful, widely used programming language.

After all, it won't stop with a type system...

Best,
Mike

On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
> Hi Steven,
>
> This is a great idea, and something I've wanted for a long time. Some
> thoughts below:
>
> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>> * generic type system should allow for generic arrays (using types
>> such as S[], F[], etc.)
>
> How would this notation be handled for user-defined types? Would it
> always access the n-th element of the variable? This would be nice.
> You could actually also access audio vectors this way.
>
> Would it be good to use a '.' notation, to access elements by name, as
> in a struct?
>
> Also, how about allowing instruments as a variable type, so you can
> use instruments as classes? Would this make sense, or would it be
> better just to design a complete class system from the ground up?
>
> Have a look at my ideas for arrays:
> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>
> I think it would also be nice to allow nested types, so you can create
> an array and then populate it with any types including arrays.
>
> Cheers,
> Andrés
>
>>
>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>> instances of instrument would count size of vars in pool, then malloc
>> one big block; locations in block assigned according to dynamic
>> counting of sizes of vars in the linked list (removing use of indexes
>> as variable locations done during compiler); I think this could be
>> made to be as efficient as the current memory allocation strategy
>>
>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>> the variable counts
>>
>> * INSTRDEF could be entry-way for host-defined instrument, where
>> "struct op * nxtop;" is replaced with a host-function hook
>>
>>
>> Code draft below.  It's probably a bit naive as I have not really
>> looked at creating type systems and will be exploring that over the
>> next week or two.  Comments and suggestions very much appreciated!
>>
>> steven
>>
>>
>>
>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>
>>    typedef struct cstype {
>>        char* varTypeName;
>>        char* varMemberName; /* Used when member of aggregate type */
>>        char* varDescription;
>>        cstype* members;
>>    } CS_TYPE;
>>
>>    typedef struct csvariable {
>>        char* varName;
>>        CS_TYPE* varType;
>>        void* memblock;
>>        int refCount;
>>    } CS_VARIABLE;
>>
>>    /* Adds a new type to Csound's type table
>>       Returns if variable type redefined */
>>    bool csoundAddVariableType(CSOUND* csound,
>>                               CS_TYPE type,
>>                               CS_VARIABLE* (*createVariable)(void*
>> initialData));
>>
>>    /* Csound Variable Pool - essentially a map
>>       CSOUND contains one for global memory, InstrDef and UDODef
>>       contain a pool for local memory
>>     */
>>
>>    typedef struct csvarpool {
>>        CS_VARIABLE* head;
>>    } CS_VAR_POOL;
>>
>>    /**
>>     * This struct is filled out by otran() at orch parse time.
>>     * It is used as a template for instrument events.
>>     */
>>    typedef struct instrdef {
>>        CS_VAR_POOL variables;
>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>                                         opcodes in instr */
>>        int16   muted;
>>        int32   localen;
>>        int32   opdstot;                /* Total size of opds structs
>> in instr */
>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>        struct insds * instance;        /* Chain of allocated instances of
>>                                         this instrument */
>>        struct insds * lst_instance;    /* last allocated instance */
>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>        /* (pointer to next one is INSDS.nxtact) */
>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>> (num order) */
>>        int     active;                 /* To count activations for control */
>>        int     maxalloc;
>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>        char    *insname;               /* instrument name */
>>        int     instcnt;                /* Count number of instances ever */
>>    } INSTRDEF;
>>
>> /* END CSOUND TYPE SYSTEM WORK */
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

This type system proposal really generalizes what's already in Csound,
which is a hard-coded type system.  It's usefulness however still
comes into play when Csound is embedded in a host language for
building instruments, as the host language would require creating
variables that Csound opcodes that read/write to.  As it is now, even
if you wrap all of the opcodes, you still need a means to connect
a-/k-/etc. vars, and you can not create them from a host language. If
on the other hand, you write the entire performance function for an
instrument and maintain state variables in the host language, you
would simply not use the type system (but you'd also not use Csound
opcodes and just Instrument as your lowest level of abstraction).

Having the type system would expose functions to the host for creating
variables, such as (in python-ish pseudo-code):

import csnd

class MyInstr(CsoundInstr):

def init():
  vco2 = csnd.opcodes["vco2"](440)
  aout = vco2.getOut(0)
  k = csound.createVariable("k", "cutoff");
  k.set(2000)
  op = csnd.opcodes["moogladder"]
  filter = op(aout,k)

def perf():
  vco2.perf()
  filter.perf()
  out.mix(filter.getOut(0))

On the other hand, I see real value in using Csound code as a domain
specific language.  This view arose from experience in using the same
CSD in the iOS and Android examples projects, and knowing it could be
used in other operating systems and languages as well.  I am imagining
too that from your own experience, you must see value in moving from
Java Silence to Python, to Lua, to C++, and still being able to reuse
instruments--something which would not be able to be done if you did
your instruments in specific programming language.

So I think in the end, both use cases of embedding in a host language
as well as extending the current csound language is supported with
this proposal.

Please let me know though if I've misunderstood anything!
steven

On Thu, May 31, 2012 at 9:40 AM, Michael Gogins
 wrote:
> I'm not sure this is wise. Permit me to explain my thinking. It's
> pretty fundamental.
>
> In the first place, having a type system in a software sound synthesis
> language is a really great idea. No argument there.
>
> However, I see a tension, in software sound synthesis systems, between
> the requirements for software sound synthesis, usually resulting in
> some sort of a data flow graph ("signal flow graph"), and the
> requirements for a programming language. The graph is needed not only
> so that the system will run fast enough, but also as an organizing
> metaphor for signal processing and sound synthesis. To the best of my
> knowledge, almost all real world, real time or near real time signal
> processing systems, for music or otherwise, use some sort of data flow
> graph.
>
> Data flow graphs with sufficient logic are Turing complete, so they
> can definitely be made into general purpose programming languages. No
> argument there.
>
> The tension arises because the objective of a data flow graph with a
> type system is challenging. This goal can be met in two ways: by
> adding a type system to a data flow graph, or by embedding a data flow
> graph into an existing programming language. There are various
> examples of this latter approach. SuperCollider sort of does this,
> CLAM, STK, and CSL actually do this (but require the C++ compiler).
>
> Historically, almost all software sound synthesis systems have started
> with a data flow graph and then added programming language features to
> that. This was done because historically, there were no general
> purpose programming languages that could run fast enough for signal
> processing without using a static compiler.
>
> That is no longer the case. There are several dynamic language
> runtimes that are fast enough for our purposes: LuaJIT, several kinds
> of JavaScript, possibly Parrot.
>
> In addition, the use of a static compiler has become more practical.
> On modern computers, compile times are short, and packaged compilers
> are easily available. A number of scientific computing systems
> presuppose that GCC is embedded in the system somewhere, and automate
> the build process.
>
> I'm quite certain that implementing a software sound synthesis system
> with a rich type system, classes, etc., etc., could be done much more
> easily by embedding a data flow graph into an existing language such
> as LuaJIT or a canned installation of GCC than by bolting more and
> more programming language features onto Csound.
>
> The functionality of Csound could be ported into such a system by
> creating a wrapper template for Csound opcodes.
>
> In addition to the back end complexities arising from adding
> programming language features to the Csound runtime, there are front
> end considerations. The user will be forced to learn a new syntax for
> operations that he or she may already be familiar with in other
> languages. Why? Plus, people have been complaining about awkward
> syntax in the Csound language for ages. These complaints could be
> resolved at one fell swoop by embedding the Csound data flow graph and
> opcodes into an existing, powerful, widely used programming language.
>
> After all, it won't stop with a type system...
>
> Best,
> Mike
>
> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>> Hi Steven,
>>
>> This is a great idea, and something I've wanted for a long time. Some
>> thoughts below:
>>
>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>> * generic type system should allow for generic arrays (using types
>>> such as S[], F[], etc.)
>>
>> How would this notation be handled for user-defined types? Would it
>> always access the n-th element of the variable? This would be nice.
>> You could actually also access audio vectors this way.
>>
>> Would it be good to use a '.' notation, to access elements by name, as
>> in a struct?
>>
>> Also, how about allowing instruments as a variable type, so you can
>> use instruments as classes? Would this make sense, or would it be
>> better just to design a complete class system from the ground up?
>>
>> Have a look at my ideas for arrays:
>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>
>> I think it would also be nice to allow nested types, so you can create
>> an array and then populate it with any types including arrays.
>>
>> Cheers,
>> Andrés
>>
>>>
>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>> instances of instrument would count size of vars in pool, then malloc
>>> one big block; locations in block assigned according to dynamic
>>> counting of sizes of vars in the linked list (removing use of indexes
>>> as variable locations done during compiler); I think this could be
>>> made to be as efficient as the current memory allocation strategy
>>>
>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>> the variable counts
>>>
>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>> "struct op * nxtop;" is replaced with a host-function hook
>>>
>>>
>>> Code draft below.  It's probably a bit naive as I have not really
>>> looked at creating type systems and will be exploring that over the
>>> next week or two.  Comments and suggestions very much appreciated!
>>>
>>> steven
>>>
>>>
>>>
>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>
>>>    typedef struct cstype {
>>>        char* varTypeName;
>>>        char* varMemberName; /* Used when member of aggregate type */
>>>        char* varDescription;
>>>        cstype* members;
>>>    } CS_TYPE;
>>>
>>>    typedef struct csvariable {
>>>        char* varName;
>>>        CS_TYPE* varType;
>>>        void* memblock;
>>>        int refCount;
>>>    } CS_VARIABLE;
>>>
>>>    /* Adds a new type to Csound's type table
>>>       Returns if variable type redefined */
>>>    bool csoundAddVariableType(CSOUND* csound,
>>>                               CS_TYPE type,
>>>                               CS_VARIABLE* (*createVariable)(void*
>>> initialData));
>>>
>>>    /* Csound Variable Pool - essentially a map
>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>       contain a pool for local memory
>>>     */
>>>
>>>    typedef struct csvarpool {
>>>        CS_VARIABLE* head;
>>>    } CS_VAR_POOL;
>>>
>>>    /**
>>>     * This struct is filled out by otran() at orch parse time.
>>>     * It is used as a template for instrument events.
>>>     */
>>>    typedef struct instrdef {
>>>        CS_VAR_POOL variables;
>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>                                         opcodes in instr */
>>>        int16   muted;
>>>        int32   localen;
>>>        int32   opdstot;                /* Total size of opds structs
>>> in instr */
>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>        struct insds * instance;        /* Chain of allocated instances of
>>>                                         this instrument */
>>>        struct insds * lst_instance;    /* last allocated instance */
>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>        /* (pointer to next one is INSDS.nxtact) */
>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>> (num order) */
>>>        int     active;                 /* To count activations for control */
>>>        int     maxalloc;
>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>        char    *insname;               /* instrument name */
>>>        int     instcnt;                /* Count number of instances ever */
>>>    } INSTRDEF;
>>>
>>> /* END CSOUND TYPE SYSTEM WORK */
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Andres,

I think for user-defined types, it'd be the same syntax for using
non-inferred types (inferred being classic csound orch usage, with
leading character determining type).  So perhaps something like this:

; define data type
data MyData kvar, avar

;define udo
opcode myOpcode a, :MyData[]:    ; colon denotes custom type
   myData xin
   xout myData[0].avar
endop

;define instr

instr 1
a1 init 0
a2 init 0
k1 init 0
k2 init 0

userdata:MyData[2]  ; initialize userData as MyData[2]
userdata[0].kvar = k1
userdata[0].avar = a1
userdata[1].kvar = k2
userdata[2].avar = a2

aout myOpcode userdata
outs aout, aout
endin

In this proposal, arrays would be homogenous, but would would allow
arrays of arrays:

asigs[4][2]  ; array of 4 arrays of 2 length
myData[2][2] ; array of 2 arrays of myData with length of 2

I think the above isn't so bad, but any suggestions appreciated! :)

steven

On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
> Hi Steven,
>
> This is a great idea, and something I've wanted for a long time. Some
> thoughts below:
>
> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>> * generic type system should allow for generic arrays (using types
>> such as S[], F[], etc.)
>
> How would this notation be handled for user-defined types? Would it
> always access the n-th element of the variable? This would be nice.
> You could actually also access audio vectors this way.
>
> Would it be good to use a '.' notation, to access elements by name, as
> in a struct?
>
> Also, how about allowing instruments as a variable type, so you can
> use instruments as classes? Would this make sense, or would it be
> better just to design a complete class system from the ground up?
>
> Have a look at my ideas for arrays:
> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>
> I think it would also be nice to allow nested types, so you can create
> an array and then populate it with any types including arrays.
>
> Cheers,
> Andrés
>
>>
>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>> instances of instrument would count size of vars in pool, then malloc
>> one big block; locations in block assigned according to dynamic
>> counting of sizes of vars in the linked list (removing use of indexes
>> as variable locations done during compiler); I think this could be
>> made to be as efficient as the current memory allocation strategy
>>
>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>> the variable counts
>>
>> * INSTRDEF could be entry-way for host-defined instrument, where
>> "struct op * nxtop;" is replaced with a host-function hook
>>
>>
>> Code draft below.  It's probably a bit naive as I have not really
>> looked at creating type systems and will be exploring that over the
>> next week or two.  Comments and suggestions very much appreciated!
>>
>> steven
>>
>>
>>
>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>
>>    typedef struct cstype {
>>        char* varTypeName;
>>        char* varMemberName; /* Used when member of aggregate type */
>>        char* varDescription;
>>        cstype* members;
>>    } CS_TYPE;
>>
>>    typedef struct csvariable {
>>        char* varName;
>>        CS_TYPE* varType;
>>        void* memblock;
>>        int refCount;
>>    } CS_VARIABLE;
>>
>>    /* Adds a new type to Csound's type table
>>       Returns if variable type redefined */
>>    bool csoundAddVariableType(CSOUND* csound,
>>                               CS_TYPE type,
>>                               CS_VARIABLE* (*createVariable)(void*
>> initialData));
>>
>>    /* Csound Variable Pool - essentially a map
>>       CSOUND contains one for global memory, InstrDef and UDODef
>>       contain a pool for local memory
>>     */
>>
>>    typedef struct csvarpool {
>>        CS_VARIABLE* head;
>>    } CS_VAR_POOL;
>>
>>    /**
>>     * This struct is filled out by otran() at orch parse time.
>>     * It is used as a template for instrument events.
>>     */
>>    typedef struct instrdef {
>>        CS_VAR_POOL variables;
>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>                                         opcodes in instr */
>>        int16   muted;
>>        int32   localen;
>>        int32   opdstot;                /* Total size of opds structs
>> in instr */
>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>        struct insds * instance;        /* Chain of allocated instances of
>>                                         this instrument */
>>        struct insds * lst_instance;    /* last allocated instance */
>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>        /* (pointer to next one is INSDS.nxtact) */
>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>> (num order) */
>>        int     active;                 /* To count activations for control */
>>        int     maxalloc;
>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>        char    *insname;               /* instrument name */
>>        int     instcnt;                /* Count number of instances ever */
>>    } INSTRDEF;
>>
>> /* END CSOUND TYPE SYSTEM WORK */
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

This looks great. The only thing I don't like is using the array index
in the declaration as the maximum number rather than the number of
elements in the array.

Cheers,
Andrés

On Thu, May 31, 2012 at 9:20 AM, Steven Yi  wrote:
> Hi Andres,
>
> I think for user-defined types, it'd be the same syntax for using
> non-inferred types (inferred being classic csound orch usage, with
> leading character determining type).  So perhaps something like this:
>
> ; define data type
> data MyData kvar, avar
>
> ;define udo
> opcode myOpcode a, :MyData[]:    ; colon denotes custom type
>   myData xin
>   xout myData[0].avar
> endop
>
> ;define instr
>
> instr 1
> a1 init 0
> a2 init 0
> k1 init 0
> k2 init 0
>
> userdata:MyData[2]  ; initialize userData as MyData[2]
> userdata[0].kvar = k1
> userdata[0].avar = a1
> userdata[1].kvar = k2
> userdata[2].avar = a2
>
> aout myOpcode userdata
> outs aout, aout
> endin
>
> In this proposal, arrays would be homogenous, but would would allow
> arrays of arrays:
>
> asigs[4][2]  ; array of 4 arrays of 2 length
> myData[2][2] ; array of 2 arrays of myData with length of 2
>
> I think the above isn't so bad, but any suggestions appreciated! :)
>
> steven
>
> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>> Hi Steven,
>>
>> This is a great idea, and something I've wanted for a long time. Some
>> thoughts below:
>>
>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>> * generic type system should allow for generic arrays (using types
>>> such as S[], F[], etc.)
>>
>> How would this notation be handled for user-defined types? Would it
>> always access the n-th element of the variable? This would be nice.
>> You could actually also access audio vectors this way.
>>
>> Would it be good to use a '.' notation, to access elements by name, as
>> in a struct?
>>
>> Also, how about allowing instruments as a variable type, so you can
>> use instruments as classes? Would this make sense, or would it be
>> better just to design a complete class system from the ground up?
>>
>> Have a look at my ideas for arrays:
>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>
>> I think it would also be nice to allow nested types, so you can create
>> an array and then populate it with any types including arrays.
>>
>> Cheers,
>> Andrés
>>
>>>
>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>> instances of instrument would count size of vars in pool, then malloc
>>> one big block; locations in block assigned according to dynamic
>>> counting of sizes of vars in the linked list (removing use of indexes
>>> as variable locations done during compiler); I think this could be
>>> made to be as efficient as the current memory allocation strategy
>>>
>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>> the variable counts
>>>
>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>> "struct op * nxtop;" is replaced with a host-function hook
>>>
>>>
>>> Code draft below.  It's probably a bit naive as I have not really
>>> looked at creating type systems and will be exploring that over the
>>> next week or two.  Comments and suggestions very much appreciated!
>>>
>>> steven
>>>
>>>
>>>
>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>
>>>    typedef struct cstype {
>>>        char* varTypeName;
>>>        char* varMemberName; /* Used when member of aggregate type */
>>>        char* varDescription;
>>>        cstype* members;
>>>    } CS_TYPE;
>>>
>>>    typedef struct csvariable {
>>>        char* varName;
>>>        CS_TYPE* varType;
>>>        void* memblock;
>>>        int refCount;
>>>    } CS_VARIABLE;
>>>
>>>    /* Adds a new type to Csound's type table
>>>       Returns if variable type redefined */
>>>    bool csoundAddVariableType(CSOUND* csound,
>>>                               CS_TYPE type,
>>>                               CS_VARIABLE* (*createVariable)(void*
>>> initialData));
>>>
>>>    /* Csound Variable Pool - essentially a map
>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>       contain a pool for local memory
>>>     */
>>>
>>>    typedef struct csvarpool {
>>>        CS_VARIABLE* head;
>>>    } CS_VAR_POOL;
>>>
>>>    /**
>>>     * This struct is filled out by otran() at orch parse time.
>>>     * It is used as a template for instrument events.
>>>     */
>>>    typedef struct instrdef {
>>>        CS_VAR_POOL variables;
>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>                                         opcodes in instr */
>>>        int16   muted;
>>>        int32   localen;
>>>        int32   opdstot;                /* Total size of opds structs
>>> in instr */
>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>        struct insds * instance;        /* Chain of allocated instances of
>>>                                         this instrument */
>>>        struct insds * lst_instance;    /* last allocated instance */
>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>        /* (pointer to next one is INSDS.nxtact) */
>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>> (num order) */
>>>        int     active;                 /* To count activations for control */
>>>        int     maxalloc;
>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>        char    *insname;               /* instrument name */
>>>        int     instcnt;                /* Count number of instances ever */
>>>    } INSTRDEF;
>>>
>>> /* END CSOUND TYPE SYSTEM WORK */
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://

Hi Andres,

I think there is a confusion due to a typo I did; I am proposing
[numItems] and not [maxIndex].  So myData[2] would have indexes of 0
and 1. Index of 2 would cause an error. So I think we're in agreement.

Thanks!
steven


On Fri, Jun 1, 2012 at 6:57 AM, Andres Cabrera  wrote:
> Hi,
>
> This looks great. The only thing I don't like is using the array index
> in the declaration as the maximum number rather than the number of
> elements in the array.
>
> Cheers,
> Andrés
>
> On Thu, May 31, 2012 at 9:20 AM, Steven Yi  wrote:
>> Hi Andres,
>>
>> I think for user-defined types, it'd be the same syntax for using
>> non-inferred types (inferred being classic csound orch usage, with
>> leading character determining type).  So perhaps something like this:
>>
>> ; define data type
>> data MyData kvar, avar
>>
>> ;define udo
>> opcode myOpcode a, :MyData[]:    ; colon denotes custom type
>>   myData xin
>>   xout myData[0].avar
>> endop
>>
>> ;define instr
>>
>> instr 1
>> a1 init 0
>> a2 init 0
>> k1 init 0
>> k2 init 0
>>
>> userdata:MyData[2]  ; initialize userData as MyData[2]
>> userdata[0].kvar = k1
>> userdata[0].avar = a1
>> userdata[1].kvar = k2
>> userdata[2].avar = a2
>>
>> aout myOpcode userdata
>> outs aout, aout
>> endin
>>
>> In this proposal, arrays would be homogenous, but would would allow
>> arrays of arrays:
>>
>> asigs[4][2]  ; array of 4 arrays of 2 length
>> myData[2][2] ; array of 2 arrays of myData with length of 2
>>
>> I think the above isn't so bad, but any suggestions appreciated! :)
>>
>> steven
>>
>> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>>> Hi Steven,
>>>
>>> This is a great idea, and something I've wanted for a long time. Some
>>> thoughts below:
>>>
>>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>>> * generic type system should allow for generic arrays (using types
>>>> such as S[], F[], etc.)
>>>
>>> How would this notation be handled for user-defined types? Would it
>>> always access the n-th element of the variable? This would be nice.
>>> You could actually also access audio vectors this way.
>>>
>>> Would it be good to use a '.' notation, to access elements by name, as
>>> in a struct?
>>>
>>> Also, how about allowing instruments as a variable type, so you can
>>> use instruments as classes? Would this make sense, or would it be
>>> better just to design a complete class system from the ground up?
>>>
>>> Have a look at my ideas for arrays:
>>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>
>>> I think it would also be nice to allow nested types, so you can create
>>> an array and then populate it with any types including arrays.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>>
>>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>>> instances of instrument would count size of vars in pool, then malloc
>>>> one big block; locations in block assigned according to dynamic
>>>> counting of sizes of vars in the linked list (removing use of indexes
>>>> as variable locations done during compiler); I think this could be
>>>> made to be as efficient as the current memory allocation strategy
>>>>
>>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>>> the variable counts
>>>>
>>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>>> "struct op * nxtop;" is replaced with a host-function hook
>>>>
>>>>
>>>> Code draft below.  It's probably a bit naive as I have not really
>>>> looked at creating type systems and will be exploring that over the
>>>> next week or two.  Comments and suggestions very much appreciated!
>>>>
>>>> steven
>>>>
>>>>
>>>>
>>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>>
>>>>    typedef struct cstype {
>>>>        char* varTypeName;
>>>>        char* varMemberName; /* Used when member of aggregate type */
>>>>        char* varDescription;
>>>>        cstype* members;
>>>>    } CS_TYPE;
>>>>
>>>>    typedef struct csvariable {
>>>>        char* varName;
>>>>        CS_TYPE* varType;
>>>>        void* memblock;
>>>>        int refCount;
>>>>    } CS_VARIABLE;
>>>>
>>>>    /* Adds a new type to Csound's type table
>>>>       Returns if variable type redefined */
>>>>    bool csoundAddVariableType(CSOUND* csound,
>>>>                               CS_TYPE type,
>>>>                               CS_VARIABLE* (*createVariable)(void*
>>>> initialData));
>>>>
>>>>    /* Csound Variable Pool - essentially a map
>>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>>       contain a pool for local memory
>>>>     */
>>>>
>>>>    typedef struct csvarpool {
>>>>        CS_VARIABLE* head;
>>>>    } CS_VAR_POOL;
>>>>
>>>>    /**
>>>>     * This struct is filled out by otran() at orch parse time.
>>>>     * It is used as a template for instrument events.
>>>>     */
>>>>    typedef struct instrdef {
>>>>        CS_VAR_POOL variables;
>>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>>                                         opcodes in instr */
>>>>        int16   muted;
>>>>        int32   localen;
>>>>        int32   opdstot;                /* Total size of opds structs
>>>> in instr */
>>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>>        struct insds * instance;        /* Chain of allocated instances of
>>>>                                         this instrument */
>>>>        struct insds * lst_instance;    /* last allocated instance */
>>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>>        /* (pointer to next one is INSDS.nxtact) */
>>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>>> (num order) */
>>>>        int     active;                 /* To count activations for control */
>>>>        int     maxalloc;
>>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>>        char    *insname;               /* instrument name */
>>>>        int     instcnt;                /* Count number of instances ever */
>>>>    } INSTRDEF;
>>>>
>>>> /* END CSOUND TYPE SYSTEM WORK */
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

I agree with you that performance of the flow graph is of paramount
importance. SuperCollider has a very lean flow graph, which is
actually more limited than the Csound flow graph, so most of the
program logic has to be done in the client, usually at the expense of
precise timing, as the messages must travel the network to the server
to be executed. However, I do think that having the "language" coupled
with the flow graph is very practical, not only for the timing but
also because you can embed more programming logic within the flow
graph itself. Additionally, this separation of "language" and "synth"
is very confusing for most musicians. I think adding the type
mechanism to Csound will really simplify many day to day tasks and
make code more readable and maintainable. I think that in many cases,
using an external language like lua is actually a huge burden
precisely because the type system in Csound is so basic, so in
pŕactice bringing data to and from those languages is usually a
cumbersome task if you need more than one or two variables. So I think
the type system actually benefits not only the Csound language but
also the interaction with other languages, because complex data
structures can be passed more transparently to and fro.

Also, I think the array system in Csound can be connected to the
parallelization engine, as arrays of opcodes are prime candidates for
parallelization.

Cheers,
Andrés

On Thu, May 31, 2012 at 8:40 AM, Michael Gogins
 wrote:
> I'm not sure this is wise. Permit me to explain my thinking. It's
> pretty fundamental.
>
> In the first place, having a type system in a software sound synthesis
> language is a really great idea. No argument there.
>
> However, I see a tension, in software sound synthesis systems, between
> the requirements for software sound synthesis, usually resulting in
> some sort of a data flow graph ("signal flow graph"), and the
> requirements for a programming language. The graph is needed not only
> so that the system will run fast enough, but also as an organizing
> metaphor for signal processing and sound synthesis. To the best of my
> knowledge, almost all real world, real time or near real time signal
> processing systems, for music or otherwise, use some sort of data flow
> graph.
>
> Data flow graphs with sufficient logic are Turing complete, so they
> can definitely be made into general purpose programming languages. No
> argument there.
>
> The tension arises because the objective of a data flow graph with a
> type system is challenging. This goal can be met in two ways: by
> adding a type system to a data flow graph, or by embedding a data flow
> graph into an existing programming language. There are various
> examples of this latter approach. SuperCollider sort of does this,
> CLAM, STK, and CSL actually do this (but require the C++ compiler).
>
> Historically, almost all software sound synthesis systems have started
> with a data flow graph and then added programming language features to
> that. This was done because historically, there were no general
> purpose programming languages that could run fast enough for signal
> processing without using a static compiler.
>
> That is no longer the case. There are several dynamic language
> runtimes that are fast enough for our purposes: LuaJIT, several kinds
> of JavaScript, possibly Parrot.
>
> In addition, the use of a static compiler has become more practical.
> On modern computers, compile times are short, and packaged compilers
> are easily available. A number of scientific computing systems
> presuppose that GCC is embedded in the system somewhere, and automate
> the build process.
>
> I'm quite certain that implementing a software sound synthesis system
> with a rich type system, classes, etc., etc., could be done much more
> easily by embedding a data flow graph into an existing language such
> as LuaJIT or a canned installation of GCC than by bolting more and
> more programming language features onto Csound.
>
> The functionality of Csound could be ported into such a system by
> creating a wrapper template for Csound opcodes.
>
> In addition to the back end complexities arising from adding
> programming language features to the Csound runtime, there are front
> end considerations. The user will be forced to learn a new syntax for
> operations that he or she may already be familiar with in other
> languages. Why? Plus, people have been complaining about awkward
> syntax in the Csound language for ages. These complaints could be
> resolved at one fell swoop by embedding the Csound data flow graph and
> opcodes into an existing, powerful, widely used programming language.
>
> After all, it won't stop with a type system...
>
> Best,
> Mike
>
> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>> Hi Steven,
>>
>> This is a great idea, and something I've wanted for a long time. Some
>> thoughts below:
>>
>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>> * generic type system should allow for generic arrays (using types
>>> such as S[], F[], etc.)
>>
>> How would this notation be handled for user-defined types? Would it
>> always access the n-th element of the variable? This would be nice.
>> You could actually also access audio vectors this way.
>>
>> Would it be good to use a '.' notation, to access elements by name, as
>> in a struct?
>>
>> Also, how about allowing instruments as a variable type, so you can
>> use instruments as classes? Would this make sense, or would it be
>> better just to design a complete class system from the ground up?
>>
>> Have a look at my ideas for arrays:
>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>
>> I think it would also be nice to allow nested types, so you can create
>> an array and then populate it with any types including arrays.
>>
>> Cheers,
>> Andrés
>>
>>>
>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>> instances of instrument would count size of vars in pool, then malloc
>>> one big block; locations in block assigned according to dynamic
>>> counting of sizes of vars in the linked list (removing use of indexes
>>> as variable locations done during compiler); I think this could be
>>> made to be as efficient as the current memory allocation strategy
>>>
>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>> the variable counts
>>>
>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>> "struct op * nxtop;" is replaced with a host-function hook
>>>
>>>
>>> Code draft below.  It's probably a bit naive as I have not really
>>> looked at creating type systems and will be exploring that over the
>>> next week or two.  Comments and suggestions very much appreciated!
>>>
>>> steven
>>>
>>>
>>>
>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>
>>>    typedef struct cstype {
>>>        char* varTypeName;
>>>        char* varMemberName; /* Used when member of aggregate type */
>>>        char* varDescription;
>>>        cstype* members;
>>>    } CS_TYPE;
>>>
>>>    typedef struct csvariable {
>>>        char* varName;
>>>        CS_TYPE* varType;
>>>        void* memblock;
>>>        int refCount;
>>>    } CS_VARIABLE;
>>>
>>>    /* Adds a new type to Csound's type table
>>>       Returns if variable type redefined */
>>>    bool csoundAddVariableType(CSOUND* csound,
>>>                               CS_TYPE type,
>>>                               CS_VARIABLE* (*createVariable)(void*
>>> initialData));
>>>
>>>    /* Csound Variable Pool - essentially a map
>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>       contain a pool for local memory
>>>     */
>>>
>>>    typedef struct csvarpool {
>>>        CS_VARIABLE* head;
>>>    } CS_VAR_POOL;
>>>
>>>    /**
>>>     * This struct is filled out by otran() at orch parse time.
>>>     * It is used as a template for instrument events.
>>>     */
>>>    typedef struct instrdef {
>>>        CS_VAR_POOL variables;
>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>                                         opcodes in instr */
>>>        int16   muted;
>>>        int32   localen;
>>>        int32   opdstot;                /* Total size of opds structs
>>> in instr */
>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>        struct insds * instance;        /* Chain of allocated instances of
>>>                                         this instrument */
>>>        struct insds * lst_instance;    /* last allocated instance */
>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>        /* (pointer to next one is INSDS.nxtact) */
>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>> (num order) */
>>>        int     active;                 /* To count activations for control */
>>>        int     maxalloc;
>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>        char    *insname;               /* instrument name */
>>>        int     instcnt;                /* Count number of instances ever */
>>>    } INSTRDEF;
>>>
>>> /* END CSOUND TYPE SYSTEM WORK */
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listin

I don't doubt that any and all programming language features can be
added to the Csound language. But I wonder if it is not making extra
work. I think it might be easier to embed the Csound graph and opcodes
in an existing language. I think the language stuff is more complex,
and harder to get right, than the graph stuff. The opcodes don't
really count since they can be wrapped.

Regards,
Mike

On Fri, Jun 1, 2012 at 12:49 PM, Andres Cabrera  wrote:
> Hi Michael,
>
> I agree with you that performance of the flow graph is of paramount
> importance. SuperCollider has a very lean flow graph, which is
> actually more limited than the Csound flow graph, so most of the
> program logic has to be done in the client, usually at the expense of
> precise timing, as the messages must travel the network to the server
> to be executed. However, I do think that having the "language" coupled
> with the flow graph is very practical, not only for the timing but
> also because you can embed more programming logic within the flow
> graph itself. Additionally, this separation of "language" and "synth"
> is very confusing for most musicians. I think adding the type
> mechanism to Csound will really simplify many day to day tasks and
> make code more readable and maintainable. I think that in many cases,
> using an external language like lua is actually a huge burden
> precisely because the type system in Csound is so basic, so in
> pŕactice bringing data to and from those languages is usually a
> cumbersome task if you need more than one or two variables. So I think
> the type system actually benefits not only the Csound language but
> also the interaction with other languages, because complex data
> structures can be passed more transparently to and fro.
>
> Also, I think the array system in Csound can be connected to the
> parallelization engine, as arrays of opcodes are prime candidates for
> parallelization.
>
> Cheers,
> Andrés
>
> On Thu, May 31, 2012 at 8:40 AM, Michael Gogins
>  wrote:
>> I'm not sure this is wise. Permit me to explain my thinking. It's
>> pretty fundamental.
>>
>> In the first place, having a type system in a software sound synthesis
>> language is a really great idea. No argument there.
>>
>> However, I see a tension, in software sound synthesis systems, between
>> the requirements for software sound synthesis, usually resulting in
>> some sort of a data flow graph ("signal flow graph"), and the
>> requirements for a programming language. The graph is needed not only
>> so that the system will run fast enough, but also as an organizing
>> metaphor for signal processing and sound synthesis. To the best of my
>> knowledge, almost all real world, real time or near real time signal
>> processing systems, for music or otherwise, use some sort of data flow
>> graph.
>>
>> Data flow graphs with sufficient logic are Turing complete, so they
>> can definitely be made into general purpose programming languages. No
>> argument there.
>>
>> The tension arises because the objective of a data flow graph with a
>> type system is challenging. This goal can be met in two ways: by
>> adding a type system to a data flow graph, or by embedding a data flow
>> graph into an existing programming language. There are various
>> examples of this latter approach. SuperCollider sort of does this,
>> CLAM, STK, and CSL actually do this (but require the C++ compiler).
>>
>> Historically, almost all software sound synthesis systems have started
>> with a data flow graph and then added programming language features to
>> that. This was done because historically, there were no general
>> purpose programming languages that could run fast enough for signal
>> processing without using a static compiler.
>>
>> That is no longer the case. There are several dynamic language
>> runtimes that are fast enough for our purposes: LuaJIT, several kinds
>> of JavaScript, possibly Parrot.
>>
>> In addition, the use of a static compiler has become more practical.
>> On modern computers, compile times are short, and packaged compilers
>> are easily available. A number of scientific computing systems
>> presuppose that GCC is embedded in the system somewhere, and automate
>> the build process.
>>
>> I'm quite certain that implementing a software sound synthesis system
>> with a rich type system, classes, etc., etc., could be done much more
>> easily by embedding a data flow graph into an existing language such
>> as LuaJIT or a canned installation of GCC than by bolting more and
>> more programming language features onto Csound.
>>
>> The functionality of Csound could be ported into such a system by
>> creating a wrapper template for Csound opcodes.
>>
>> In addition to the back end complexities arising from adding
>> programming language features to the Csound runtime, there are front
>> end considerations. The user will be forced to learn a new syntax for
>> operations that he or she may already be familiar with in other
>> languages. Why? Plus, people have been complaining about awkward
>> syntax in the Csound language for ages. These complaints could be
>> resolved at one fell swoop by embedding the Csound data flow graph and
>> opcodes into an existing, powerful, widely used programming language.
>>
>> After all, it won't stop with a type system...
>>
>> Best,
>> Mike
>>
>> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>>> Hi Steven,
>>>
>>> This is a great idea, and something I've wanted for a long time. Some
>>> thoughts below:
>>>
>>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>>> * generic type system should allow for generic arrays (using types
>>>> such as S[], F[], etc.)
>>>
>>> How would this notation be handled for user-defined types? Would it
>>> always access the n-th element of the variable? This would be nice.
>>> You could actually also access audio vectors this way.
>>>
>>> Would it be good to use a '.' notation, to access elements by name, as
>>> in a struct?
>>>
>>> Also, how about allowing instruments as a variable type, so you can
>>> use instruments as classes? Would this make sense, or would it be
>>> better just to design a complete class system from the ground up?
>>>
>>> Have a look at my ideas for arrays:
>>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>
>>> I think it would also be nice to allow nested types, so you can create
>>> an array and then populate it with any types including arrays.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>>
>>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>>> instances of instrument would count size of vars in pool, then malloc
>>>> one big block; locations in block assigned according to dynamic
>>>> counting of sizes of vars in the linked list (removing use of indexes
>>>> as variable locations done during compiler); I think this could be
>>>> made to be as efficient as the current memory allocation strategy
>>>>
>>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>>> the variable counts
>>>>
>>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>>> "struct op * nxtop;" is replaced with a host-function hook
>>>>
>>>>
>>>> Code draft below.  It's probably a bit naive as I have not really
>>>> looked at creating type systems and will be exploring that over the
>>>> next week or two.  Comments and suggestions very much appreciated!
>>>>
>>>> steven
>>>>
>>>>
>>>>
>>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>>
>>>>    typedef struct cstype {
>>>>        char* varTypeName;
>>>>        char* varMemberName; /* Used when member of aggregate type */
>>>>        char* varDescription;
>>>>        cstype* members;
>>>>    } CS_TYPE;
>>>>
>>>>    typedef struct csvariable {
>>>>        char* varName;
>>>>        CS_TYPE* varType;
>>>>        void* memblock;
>>>>        int refCount;
>>>>    } CS_VARIABLE;
>>>>
>>>>    /* Adds a new type to Csound's type table
>>>>       Returns if variable type redefined */
>>>>    bool csoundAddVariableType(CSOUND* csound,
>>>>                               CS_TYPE type,
>>>>                               CS_VARIABLE* (*createVariable)(void*
>>>> initialData));
>>>>
>>>>    /* Csound Variable Pool - essentially a map
>>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>>       contain a pool for local memory
>>>>     */
>>>>
>>>>    typedef struct csvarpool {
>>>>        CS_VARIABLE* head;
>>>>    } CS_VAR_POOL;
>>>>
>>>>    /**
>>>>     * This struct is filled out by otran() at orch parse time.
>>>>     * It is used as a template for instrument events.
>>>>     */
>>>>    typedef struct instrdef {
>>>>        CS_VAR_POOL variables;
>>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>>                                         opcodes in instr */
>>>>        int16   muted;
>>>>        int32   localen;
>>>>        int32   opdstot;                /* Total size of opds structs
>>>> in instr */
>>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>>        struct insds * instance;        /* Chain of allocated instances of
>>>>                                         this instrument */
>>>>        struct insds * lst_instance;    /* last allocated instance */
>>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>>        /* (pointer to next one is INSDS.nxtact) */
>>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>>> (num order) */
>>>>        int     active;                 /* To count activations for control */
>>>>        int     maxalloc;
>>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>>        char    *insname;               /* instrument name */
>>>>        int     instcnt;                /* Count number of instances ever */
>>>>    } INSTRDEF;
>>>>
>>>> /* END CSOUND TYPE SYSTEM WORK */
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.so

Hi Michael,

Could you elaborate further then what you are envisioning for changes
to Csound for graphs and embedding? (Perhaps with pseudo-code examples
to illustrate?) Perhaps that will shed some light for me (I thought I
understood your point of view, but I'm doubting my understanding now).

I do understand your reservations about extending the language.
Certainly the type system would not be trivial; no argument there.
For myself, I just don't see how we can keep going with the current
hardcoded system and account for all the use cases that have been
proposed with dynamic modifications, arrays, etc. One of the big
reasons I've been proposing the type system change is that I think it
will ultimately simplify the internals and internal API, at the cost
of short term work. Also, I think it will ease host-language
modification as, as well as enable new features too.  I see it as
foundation work that should be done.

Thanks!
steven

On Fri, Jun 1, 2012 at 2:45 PM, Michael Gogins  wrote:
> I don't doubt that any and all programming language features can be
> added to the Csound language. But I wonder if it is not making extra
> work. I think it might be easier to embed the Csound graph and opcodes
> in an existing language. I think the language stuff is more complex,
> and harder to get right, than the graph stuff. The opcodes don't
> really count since they can be wrapped.
>
> Regards,
> Mike
>
> On Fri, Jun 1, 2012 at 12:49 PM, Andres Cabrera  wrote:
>> Hi Michael,
>>
>> I agree with you that performance of the flow graph is of paramount
>> importance. SuperCollider has a very lean flow graph, which is
>> actually more limited than the Csound flow graph, so most of the
>> program logic has to be done in the client, usually at the expense of
>> precise timing, as the messages must travel the network to the server
>> to be executed. However, I do think that having the "language" coupled
>> with the flow graph is very practical, not only for the timing but
>> also because you can embed more programming logic within the flow
>> graph itself. Additionally, this separation of "language" and "synth"
>> is very confusing for most musicians. I think adding the type
>> mechanism to Csound will really simplify many day to day tasks and
>> make code more readable and maintainable. I think that in many cases,
>> using an external language like lua is actually a huge burden
>> precisely because the type system in Csound is so basic, so in
>> pŕactice bringing data to and from those languages is usually a
>> cumbersome task if you need more than one or two variables. So I think
>> the type system actually benefits not only the Csound language but
>> also the interaction with other languages, because complex data
>> structures can be passed more transparently to and fro.
>>
>> Also, I think the array system in Csound can be connected to the
>> parallelization engine, as arrays of opcodes are prime candidates for
>> parallelization.
>>
>> Cheers,
>> Andrés
>>
>> On Thu, May 31, 2012 at 8:40 AM, Michael Gogins
>>  wrote:
>>> I'm not sure this is wise. Permit me to explain my thinking. It's
>>> pretty fundamental.
>>>
>>> In the first place, having a type system in a software sound synthesis
>>> language is a really great idea. No argument there.
>>>
>>> However, I see a tension, in software sound synthesis systems, between
>>> the requirements for software sound synthesis, usually resulting in
>>> some sort of a data flow graph ("signal flow graph"), and the
>>> requirements for a programming language. The graph is needed not only
>>> so that the system will run fast enough, but also as an organizing
>>> metaphor for signal processing and sound synthesis. To the best of my
>>> knowledge, almost all real world, real time or near real time signal
>>> processing systems, for music or otherwise, use some sort of data flow
>>> graph.
>>>
>>> Data flow graphs with sufficient logic are Turing complete, so they
>>> can definitely be made into general purpose programming languages. No
>>> argument there.
>>>
>>> The tension arises because the objective of a data flow graph with a
>>> type system is challenging. This goal can be met in two ways: by
>>> adding a type system to a data flow graph, or by embedding a data flow
>>> graph into an existing programming language. There are various
>>> examples of this latter approach. SuperCollider sort of does this,
>>> CLAM, STK, and CSL actually do this (but require the C++ compiler).
>>>
>>> Historically, almost all software sound synthesis systems have started
>>> with a data flow graph and then added programming language features to
>>> that. This was done because historically, there were no general
>>> purpose programming languages that could run fast enough for signal
>>> processing without using a static compiler.
>>>
>>> That is no longer the case. There are several dynamic language
>>> runtimes that are fast enough for our purposes: LuaJIT, several kinds
>>> of JavaScript, possibly Parrot.
>>>
>>> In addition, the use of a static compiler has become more practical.
>>> On modern computers, compile times are short, and packaged compilers
>>> are easily available. A number of scientific computing systems
>>> presuppose that GCC is embedded in the system somewhere, and automate
>>> the build process.
>>>
>>> I'm quite certain that implementing a software sound synthesis system
>>> with a rich type system, classes, etc., etc., could be done much more
>>> easily by embedding a data flow graph into an existing language such
>>> as LuaJIT or a canned installation of GCC than by bolting more and
>>> more programming language features onto Csound.
>>>
>>> The functionality of Csound could be ported into such a system by
>>> creating a wrapper template for Csound opcodes.
>>>
>>> In addition to the back end complexities arising from adding
>>> programming language features to the Csound runtime, there are front
>>> end considerations. The user will be forced to learn a new syntax for
>>> operations that he or she may already be familiar with in other
>>> languages. Why? Plus, people have been complaining about awkward
>>> syntax in the Csound language for ages. These complaints could be
>>> resolved at one fell swoop by embedding the Csound data flow graph and
>>> opcodes into an existing, powerful, widely used programming language.
>>>
>>> After all, it won't stop with a type system...
>>>
>>> Best,
>>> Mike
>>>
>>> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>>>> Hi Steven,
>>>>
>>>> This is a great idea, and something I've wanted for a long time. Some
>>>> thoughts below:
>>>>
>>>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>>>> * generic type system should allow for generic arrays (using types
>>>>> such as S[], F[], etc.)
>>>>
>>>> How would this notation be handled for user-defined types? Would it
>>>> always access the n-th element of the variable? This would be nice.
>>>> You could actually also access audio vectors this way.
>>>>
>>>> Would it be good to use a '.' notation, to access elements by name, as
>>>> in a struct?
>>>>
>>>> Also, how about allowing instruments as a variable type, so you can
>>>> use instruments as classes? Would this make sense, or would it be
>>>> better just to design a complete class system from the ground up?
>>>>
>>>> Have a look at my ideas for arrays:
>>>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>
>>>> I think it would also be nice to allow nested types, so you can create
>>>> an array and then populate it with any types including arrays.
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>>
>>>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>>>> instances of instrument would count size of vars in pool, then malloc
>>>>> one big block; locations in block assigned according to dynamic
>>>>> counting of sizes of vars in the linked list (removing use of indexes
>>>>> as variable locations done during compiler); I think this could be
>>>>> made to be as efficient as the current memory allocation strategy
>>>>>
>>>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>>>> the variable counts
>>>>>
>>>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>>>> "struct op * nxtop;" is replaced with a host-function hook
>>>>>
>>>>>
>>>>> Code draft below.  It's probably a bit naive as I have not really
>>>>> looked at creating type systems and will be exploring that over the
>>>>> next week or two.  Comments and suggestions very much appreciated!
>>>>>
>>>>> steven
>>>>>
>>>>>
>>>>>
>>>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>>>
>>>>>    typedef struct cstype {
>>>>>        char* varTypeName;
>>>>>        char* varMemberName; /* Used when member of aggregate type */
>>>>>        char* varDescription;
>>>>>        cstype* members;
>>>>>    } CS_TYPE;
>>>>>
>>>>>    typedef struct csvariable {
>>>>>        char* varName;
>>>>>        CS_TYPE* varType;
>>>>>        void* memblock;
>>>>>        int refCount;
>>>>>    } CS_VARIABLE;
>>>>>
>>>>>    /* Adds a new type to Csound's type table
>>>>>       Returns if variable type redefined */
>>>>>    bool csoundAddVariableType(CSOUND* csound,
>>>>>                               CS_TYPE type,
>>>>>                               CS_VARIABLE* (*createVariable)(void*
>>>>> initialData));
>>>>>
>>>>>    /* Csound Variable Pool - essentially a map
>>>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>>>       contain a pool for local memory
>>>>>     */
>>>>>
>>>>>    typedef struct csvarpool {
>>>>>        CS_VARIABLE* head;
>>>>>    } CS_VAR_POOL;
>>>>>
>>>>>    /**
>>>>>     * This struct is filled out by otran() at orch parse time.
>>>>>     * It is used as a template for instrument events.
>>>>>     */
>>>>>    typedef struct instrdef {
>>>>>        CS_VAR_POOL variables;
>>>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>>>                                         opcodes in instr */
>>>>>        int16   muted;
>>>>>        int32   localen;
>>>>>        int32   opdstot;                /* Total size of opds structs
>>>>> in instr */
>>>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>>>        struct insds * instance;        /* Chain of allocated instances of
>>>>>                                         this instrument */
>>>>>        struct insds * lst_instance;    /* last allocated instance */
>>>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>>>        /* (pointer to next one is INSDS.nxtact) */
>>>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>>>> (num order) */
>>>>>        int     active;                 /* To count activations for control */
>>>>>        int     maxalloc;
>>>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>>>        char    *insname;               /* instrument name */
>>>>>        int     instcnt;                /* Count number of instances ever */
>>>>>    } INSTRDEF;
>>>>>
>>>>> /* END CSOUND TYPE SYSTEM WORK */
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csou

I will be happy to elaborate further. I will do that sometime later
today or in the next few days.

Best,
Mike

On Fri, Jun 1, 2012 at 4:40 PM, Steven Yi  wrote:
> Hi Michael,
>
> Could you elaborate further then what you are envisioning for changes
> to Csound for graphs and embedding? (Perhaps with pseudo-code examples
> to illustrate?) Perhaps that will shed some light for me (I thought I
> understood your point of view, but I'm doubting my understanding now).
>
> I do understand your reservations about extending the language.
> Certainly the type system would not be trivial; no argument there.
> For myself, I just don't see how we can keep going with the current
> hardcoded system and account for all the use cases that have been
> proposed with dynamic modifications, arrays, etc. One of the big
> reasons I've been proposing the type system change is that I think it
> will ultimately simplify the internals and internal API, at the cost
> of short term work. Also, I think it will ease host-language
> modification as, as well as enable new features too.  I see it as
> foundation work that should be done.
>
> Thanks!
> steven
>
> On Fri, Jun 1, 2012 at 2:45 PM, Michael Gogins  wrote:
>> I don't doubt that any and all programming language features can be
>> added to the Csound language. But I wonder if it is not making extra
>> work. I think it might be easier to embed the Csound graph and opcodes
>> in an existing language. I think the language stuff is more complex,
>> and harder to get right, than the graph stuff. The opcodes don't
>> really count since they can be wrapped.
>>
>> Regards,
>> Mike
>>
>> On Fri, Jun 1, 2012 at 12:49 PM, Andres Cabrera  wrote:
>>> Hi Michael,
>>>
>>> I agree with you that performance of the flow graph is of paramount
>>> importance. SuperCollider has a very lean flow graph, which is
>>> actually more limited than the Csound flow graph, so most of the
>>> program logic has to be done in the client, usually at the expense of
>>> precise timing, as the messages must travel the network to the server
>>> to be executed. However, I do think that having the "language" coupled
>>> with the flow graph is very practical, not only for the timing but
>>> also because you can embed more programming logic within the flow
>>> graph itself. Additionally, this separation of "language" and "synth"
>>> is very confusing for most musicians. I think adding the type
>>> mechanism to Csound will really simplify many day to day tasks and
>>> make code more readable and maintainable. I think that in many cases,
>>> using an external language like lua is actually a huge burden
>>> precisely because the type system in Csound is so basic, so in
>>> pŕactice bringing data to and from those languages is usually a
>>> cumbersome task if you need more than one or two variables. So I think
>>> the type system actually benefits not only the Csound language but
>>> also the interaction with other languages, because complex data
>>> structures can be passed more transparently to and fro.
>>>
>>> Also, I think the array system in Csound can be connected to the
>>> parallelization engine, as arrays of opcodes are prime candidates for
>>> parallelization.
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Thu, May 31, 2012 at 8:40 AM, Michael Gogins
>>>  wrote:
>>>> I'm not sure this is wise. Permit me to explain my thinking. It's
>>>> pretty fundamental.
>>>>
>>>> In the first place, having a type system in a software sound synthesis
>>>> language is a really great idea. No argument there.
>>>>
>>>> However, I see a tension, in software sound synthesis systems, between
>>>> the requirements for software sound synthesis, usually resulting in
>>>> some sort of a data flow graph ("signal flow graph"), and the
>>>> requirements for a programming language. The graph is needed not only
>>>> so that the system will run fast enough, but also as an organizing
>>>> metaphor for signal processing and sound synthesis. To the best of my
>>>> knowledge, almost all real world, real time or near real time signal
>>>> processing systems, for music or otherwise, use some sort of data flow
>>>> graph.
>>>>
>>>> Data flow graphs with sufficient logic are Turing complete, so they
>>>> can definitely be made into general purpose programming languages. No
>>>> argument there.
>>>>
>>>> The tension arises because the objective of a data flow graph with a
>>>> type system is challenging. This goal can be met in two ways: by
>>>> adding a type system to a data flow graph, or by embedding a data flow
>>>> graph into an existing programming language. There are various
>>>> examples of this latter approach. SuperCollider sort of does this,
>>>> CLAM, STK, and CSL actually do this (but require the C++ compiler).
>>>>
>>>> Historically, almost all software sound synthesis systems have started
>>>> with a data flow graph and then added programming language features to
>>>> that. This was done because historically, there were no general
>>>> purpose programming languages that could run fast enough for signal
>>>> processing without using a static compiler.
>>>>
>>>> That is no longer the case. There are several dynamic language
>>>> runtimes that are fast enough for our purposes: LuaJIT, several kinds
>>>> of JavaScript, possibly Parrot.
>>>>
>>>> In addition, the use of a static compiler has become more practical.
>>>> On modern computers, compile times are short, and packaged compilers
>>>> are easily available. A number of scientific computing systems
>>>> presuppose that GCC is embedded in the system somewhere, and automate
>>>> the build process.
>>>>
>>>> I'm quite certain that implementing a software sound synthesis system
>>>> with a rich type system, classes, etc., etc., could be done much more
>>>> easily by embedding a data flow graph into an existing language such
>>>> as LuaJIT or a canned installation of GCC than by bolting more and
>>>> more programming language features onto Csound.
>>>>
>>>> The functionality of Csound could be ported into such a system by
>>>> creating a wrapper template for Csound opcodes.
>>>>
>>>> In addition to the back end complexities arising from adding
>>>> programming language features to the Csound runtime, there are front
>>>> end considerations. The user will be forced to learn a new syntax for
>>>> operations that he or she may already be familiar with in other
>>>> languages. Why? Plus, people have been complaining about awkward
>>>> syntax in the Csound language for ages. These complaints could be
>>>> resolved at one fell swoop by embedding the Csound data flow graph and
>>>> opcodes into an existing, powerful, widely used programming language.
>>>>
>>>> After all, it won't stop with a type system...
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>> On Thu, May 31, 2012 at 8:05 AM, Andres Cabrera  wrote:
>>>>> Hi Steven,
>>>>>
>>>>> This is a great idea, and something I've wanted for a long time. Some
>>>>> thoughts below:
>>>>>
>>>>> On Wed, May 30, 2012 at 3:55 PM, Steven Yi  wrote:
>>>>>> * generic type system should allow for generic arrays (using types
>>>>>> such as S[], F[], etc.)
>>>>>
>>>>> How would this notation be handled for user-defined types? Would it
>>>>> always access the n-th element of the variable? This would be nice.
>>>>> You could actually also access audio vectors this way.
>>>>>
>>>>> Would it be good to use a '.' notation, to access elements by name, as
>>>>> in a struct?
>>>>>
>>>>> Also, how about allowing instruments as a variable type, so you can
>>>>> use instruments as classes? Would this make sense, or would it be
>>>>> better just to design a complete class system from the ground up?
>>>>>
>>>>> Have a look at my ideas for arrays:
>>>>> http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>>
>>>>> I think it would also be nice to allow nested types, so you can create
>>>>> an array and then populate it with any types including arrays.
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>>>
>>>>>> * the CS_VAR_POOL would hold pre-allocated memory; allocation of new
>>>>>> instances of instrument would count size of vars in pool, then malloc
>>>>>> one big block; locations in block assigned according to dynamic
>>>>>> counting of sizes of vars in the linked list (removing use of indexes
>>>>>> as variable locations done during compiler); I think this could be
>>>>>> made to be as efficient as the current memory allocation strategy
>>>>>>
>>>>>> * INSTRDEF would replace INSTRTXT, using var pool instead of all of
>>>>>> the variable counts
>>>>>>
>>>>>> * INSTRDEF could be entry-way for host-defined instrument, where
>>>>>> "struct op * nxtop;" is replaced with a host-function hook
>>>>>>
>>>>>>
>>>>>> Code draft below.  It's probably a bit naive as I have not really
>>>>>> looked at creating type systems and will be exploring that over the
>>>>>> next week or two.  Comments and suggestions very much appreciated!
>>>>>>
>>>>>> steven
>>>>>>
>>>>>>
>>>>>>
>>>>>> /* BEGIN CSOUND TYPE SYSTEM WORK */
>>>>>>
>>>>>>    typedef struct cstype {
>>>>>>        char* varTypeName;
>>>>>>        char* varMemberName; /* Used when member of aggregate type */
>>>>>>        char* varDescription;
>>>>>>        cstype* members;
>>>>>>    } CS_TYPE;
>>>>>>
>>>>>>    typedef struct csvariable {
>>>>>>        char* varName;
>>>>>>        CS_TYPE* varType;
>>>>>>        void* memblock;
>>>>>>        int refCount;
>>>>>>    } CS_VARIABLE;
>>>>>>
>>>>>>    /* Adds a new type to Csound's type table
>>>>>>       Returns if variable type redefined */
>>>>>>    bool csoundAddVariableType(CSOUND* csound,
>>>>>>                               CS_TYPE type,
>>>>>>                               CS_VARIABLE* (*createVariable)(void*
>>>>>> initialData));
>>>>>>
>>>>>>    /* Csound Variable Pool - essentially a map
>>>>>>       CSOUND contains one for global memory, InstrDef and UDODef
>>>>>>       contain a pool for local memory
>>>>>>     */
>>>>>>
>>>>>>    typedef struct csvarpool {
>>>>>>        CS_VARIABLE* head;
>>>>>>    } CS_VAR_POOL;
>>>>>>
>>>>>>    /**
>>>>>>     * This struct is filled out by otran() at orch parse time.
>>>>>>     * It is used as a template for instrument events.
>>>>>>     */
>>>>>>    typedef struct instrdef {
>>>>>>        CS_VAR_POOL variables;
>>>>>>        struct op * nxtop;              /* Linked list of instr opcodes */
>>>>>>        TEXT    t;                      /* Text of instrument (same in nxtop) */
>>>>>>        int     pmax, vmax, pextrab;    /* Arg count, size of data for all
>>>>>>                                         opcodes in instr */
>>>>>>        int16   muted;
>>>>>>        int32   localen;
>>>>>>        int32   opdstot;                /* Total size of opds structs
>>>>>> in instr */
>>>>>>        MYFLT   *psetdata;              /* Used for pset opcode */
>>>>>>        struct insds * instance;        /* Chain of allocated instances of
>>>>>>                                         this instrument */
>>>>>>        struct insds * lst_instance;    /* last allocated instance */
>>>>>>        struct insds * act_instance;    /* Chain of free (inactive) instances */
>>>>>>        /* (pointer to next one is INSDS.nxtact) */
>>>>>>        struct instr2 * nxtinstxt;       /* Next instrument in orch
>>>>>> (num order) */
>>>>>>        int     active;                 /* To count activations for control */
>>>>>>        int     maxalloc;
>>>>>>        MYFLT   cpuload;                /* % load this instrumemnt makes */
>>>>>>        char    *insname;               /* instrument name */
>>>>>>        int     instcnt;                /* Count number of instances ever */
>>>>>>    } INSTRDEF;
>>>>>>
>>>>>> /* END CSOUND TYPE SYSTEM WORK */
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists