I haven't had a chance to read the score or play with this, but the
orginization, order, and naming of calls looks good to me.

Is there a chance in this to set the orc as a string, and also to set
the sco as a string? Then the whole API could be used to treat Csound
truly as a self-contained "engine." If so, could you add these calls
to your examples?

What is the reasoning to pass OPARMS to csoundCreate, rather than have
a separate setter for parameters? Or a whole suite of setters/getters
one for each parameter? Or a dictionary of parameters and values?

Regards,
Mike

On Tue, May 8, 2012 at 7:39 AM, Tito Latini  wrote:
> I have moved (not applied) a part of `csoundCompile' in  `csoundStart'.
> It allows
>
> 1)
>    csoundCreate
>    csoundCompile
>    csoundStart
>
> 2)
>    csoundCreate
>    csoundInitModules
>    csoundCompileOrc
>    csoundReadScore
>    csoundStart
>
> 3)
>    csoundCreate
>    csoundInitModules
>    csoundParseTree
>    csoundCompileTree
>    csoundReadScore
>    csoundStart
>
> Let me know if it is good for you.
>
> You see `csoundInitModules' after `csoundCreate' in {2,3} because,
> in a recent commit, I have inserted again `csoundInitModules'
> in `csoundCompile' because it has to be after `argdecode'.
>
> Thoughts for the future: the possibility to pass a param struct
> (OPARMS or other) to `csoundCreate'. It is useful without csd file and
> avoids the command line interface in another context.
>
> 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



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

Shouldn't these be const char *? The csound engine should parse the
text and then not rely on the text data being valid after the function
call. (Is const char * the way to express this?)

Cheers,
Andrés

On Tue, May 8, 2012 at 1:30 PM, Tito Latini  wrote:
>> Is there a chance in this to set the orc as a string, and also to set
>> the sco as a string? ...
>
> Yes, we have `csoundCompileOrc' and `csoundReadScore' in cs6
>
>    PUBLIC int csoundCompileOrc(CSOUND *csound, char *str);
>    PUBLIC int csoundReadScore(CSOUND *csound, char *str);
>
> and also
>
>    PUBLIC TREE *csoundParseOrc(CSOUND *csound, char *str);
>    PUBLIC int csoundCompileTree(CSOUND *csound, TREE *root);
>
>> What is the reasoning to pass OPARMS to csoundCreate, rather than have
>> a separate setter for parameters? Or a whole suite of setters/getters
>> one for each parameter? Or a dictionary of parameters and values?
>
> I see the OPARMS struct like `Pa_StreamParameters' for `Pa_OpenStream'
> in PortAudio or `SF_INFO' in sndlib. However, I am not preference,
> setter/getter or suit is good for me.
>
> 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
ht

Yes, the string orc and sco are good but they should be const char *.

I would prefer not exposing structures in the API. Something like int
csoundSetParam(CSOUND *, const char *param, const char *value); and
const char *csoundGetParam(const char *param); is what I would do.
Maybe another variant for numeric parameters.

Regards,
Mike

On Tue, May 8, 2012 at 8:30 AM, Tito Latini  wrote:
>> Is there a chance in this to set the orc as a string, and also to set
>> the sco as a string? ...
>
> Yes, we have `csoundCompileOrc' and `csoundReadScore' in cs6
>
>    PUBLIC int csoundCompileOrc(CSOUND *csound, char *str);
>    PUBLIC int csoundReadScore(CSOUND *csound, char *str);
>
> and also
>
>    PUBLIC TREE *csoundParseOrc(CSOUND *csound, char *str);
>    PUBLIC int csoundCompileTree(CSOUND *csound, TREE *root);
>
>> What is the reasoning to pass OPARMS to csoundCreate, rather than have
>> a separate setter for parameters? Or a whole suite of setters/getters
>> one for each parameter? Or a dictionary of parameters and values?
>
> I see the OPARMS struct like `Pa_StreamParameters' for `Pa_OpenStream'
> in PortAudio or `SF_INFO' in sndlib. However, I am not preference,
> setter/getter or suit is good for me.
>
> 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



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

On Tue, May 8, 2012 at 9:25 AM, Michael Gogins  wrote:
> I would prefer not exposing structures in the API. Something like int
> csoundSetParam(CSOUND *, const char *param, const char *value); and
> const char *csoundGetParam(const char *param); is what I would do.
> Maybe another variant for numeric parameters.

If callers can be relied upon to know the type of parameter, then they
could be const void * instead of const char*.

csoundSetParam(CSOUND *, const char *param, const void *value);
const void *csoundGetParam(const char *param);


-- 

Saludos,
Felipe Sateler

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