On 31 May 2012 14:40, Michael Gogins <michael.gogins@gmail.com> wrote:
Hi Mike,

Since I'm not a programmer I cannot comment on the technicalities of Steven's proposal. However, your comment below clearly comes from an expert programmer's perspective. On the other hand what if one does not know languages other than Csound? Then the reveres can be argued from the other side. a widely used programming language is not by any stretch of the imagination widely used by musician and it seems to be that there is a case to be made in favour of extending Csound's syntax: the general none-programmer (beyond Csound) musician will find it more accessible, even if this may not be an efficient programming approach.

I sometimes look at my friends coding away at Supercollider, generating algorithmic frameworks purely in SC and I envy them. Creating similar algorithms in Csound would either require UDOs or, more efficiently, the use of another language. But it seems to me that many would rather learn SC than python if it comes to it (I'm not talking about myself here), and I don't blame them because it is more accessible to the non-expert programmer.

Best,
Peiman
 
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 <mantaraya36@gmail.com> 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 <stevenyi@gmail.com> 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<string,csvar>
>>       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