I still do not see the need and really dislike the syntax -- seems
unreadable to me.
==John ffitch

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

Well, I imagine most of the people who might use this would be
building tools to use it, and would not be typing it out themselves,
though as mentioned "Convenience methods/functions/classes/etc. could
be made to ease all this." The parser would be retrofitted to use it,
and other host languages could use it as well.

Currently there are no alternatives in the current codebase that
expose this level of instrument/graph building.

WIth the generic type system, it facilitates:

* Ability to construct graphs piece by piece (pd-style programs could
be created)
* Ability to programmatically add new types
* Ability to generically handle arrays (arrays of any type)
* Ability to have debug mode for instruments, and easier monitoring of
variables, as variables keep their names

The proposed API methods were just a proposal.  I suspect more
straightforward solutions to arise once a basic foundation is created.




On Sun, Jun 10, 2012 at 1:25 PM, john ffitch  wrote:
> I still do not see the need and really dislike the syntax -- seems
> unreadable to me.
> ==John ffitch
>
> ------------------------------------------------------------------------------
> 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

I am supportive of these ideas (of course I am, we have discussed it at length when Steven was here ;). 
But I think we can refine them in time.

Regards

Victor
On 11 Jun 2012, at 16:40, Steven Yi wrote:

> Well, I imagine most of the people who might use this would be
> building tools to use it, and would not be typing it out themselves,
> though as mentioned "Convenience methods/functions/classes/etc. could
> be made to ease all this." The parser would be retrofitted to use it,
> and other host languages could use it as well.
> 
> Currently there are no alternatives in the current codebase that
> expose this level of instrument/graph building.
> 
> WIth the generic type system, it facilitates:
> 
> * Ability to construct graphs piece by piece (pd-style programs could
> be created)
> * Ability to programmatically add new types
> * Ability to generically handle arrays (arrays of any type)
> * Ability to have debug mode for instruments, and easier monitoring of
> variables, as variables keep their names
> 
> The proposed API methods were just a proposal.  I suspect more
> straightforward solutions to arise once a basic foundation is created.
> 
> 
> 
> 
> On Sun, Jun 10, 2012 at 1:25 PM, john ffitch  wrote:
>> I still do not see the need and really dislike the syntax -- seems
>> unreadable to me.
>> ==John ffitch
>> 
>> ------------------------------------------------------------------------------
>> 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

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
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 Tito,

Exposing the tree is one possibility we have discussed before and
probably should be done.  I can see usefulness in a simple means to
store/load TREE's via XML, JSON, etc.  However, I see usefulness in
being able to query/manipulate the live graph as well.

As for CSP calls, we should probably make a separate
csound_analyze_parallel() or something like that, so that it could be
used with TREE's not made by the internal parser, i.e.:

1. parse
2. handle expressions, collapse tree
3. prepare for parallel
4. compile to INSTRTXT

I think having it as a separate tree-walk rather than inline into the
bison parser may make it easier to work with and have one point of
code to #ifdef guard, rather than the many that are in csound_orc.y at
the moment.  (Though, I am making assumptions about the CSP code, as I
have not looked at it thoroughly).

Thanks!
seven

On Tue, Jun 12, 2012 at 5:32 AM, Tito Latini  wrote:
>> Currently there are no alternatives in the current codebase that
>> expose this level of instrument/graph building.
>
> There is an open door because csound.h contains `csoundCompileTree',
> ORCTOKEN and TREE struct. Perhaps it is useful to simplify the
> possible alternatives, otherwise it is only a memo.
>
>  0) mapping for the tokens of `bison' in csound_orc.y
>
>     csound.h:
>
>       typedef enum {
>           CS_TOKEN_LABEL,
>           CS_TOKEN_OPCODE_NO_OUTPUT,
>           CS_TOKEN_OPCODE,
>           ...
>       } CSOUND_TOKENS;
>
>     Engine/somefile.h:
>
>       const int csound_token[] = {
>           LABEL_TOKEN,
>           T_OPCODE0,
>           T_OPCODE,
>           ...
>           T_IDENT_I,
>           T_IDENT_GI,
>           T_IDENT_K,
>           T_IDENT_GK,
>           ...
>       };
>
>     where LABEL_TOKEN, T_OPCODE, etc are the tokens used in csound_orc.y
>
>  1) some utilities (API) to call `make_node' and `make_leaf'
>     (csound_orc_semantics.c) with CSOUND_TOKENS. Example:
>
>     PUBLIC TREE* csoundMakeLeaf(CSOUND *csound, int line, int locn, int type, ORCTOKEN *v)
>     {
>         if (type < 0 || type >= num_of_tokens)
>             type = UNKNOWN_TYPE; /* error handled by the compiler */
>                                  /* the alternative is error+exit */
>
>         return make_leaf(csound, line, locn, csound_token[type], v);
>     }
>
>     where a possible call is
>
>       csoundMakeLeaf(cs, line, locn, CS_TOKEN_OPCODE, orctoken)
>
>  10) API to call `csp_orc_...'
>
>  11) perhaps other facilities
>
> tito
>
> ------------------------------------------------------------------------------
> 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