For Csound 6 with MinGW 4.6.2 on Windows 8 Premium Home Edition, I
have built Csound64, the Csound library, the STK opcodes, CsoundAC,
and the Python and Lua interfaces for both Csound and CsoundAC.

Changes to sources include restoring #fdef'd API functions back into
the CSOUND struct, because some of the functions are used by plugins
(such as the FLTK opcodes) that I am building. The motive for putting
these functions into the struct is not just to mimic a class, but to
remove the necessity for plugins to link with the Csound library.
Please do not remove these API functions from the struct unless you
also fix dependent plugins not to need them.

I made other minor changes as required to satisfy MinGW 4.6.2. One was
to #include  not , this is now standard.

C++ compiler flags that I have not pushed yet:

-include cmath (fixes bug introduced by SWIG and Python clashing with
std namespace for hypot)
-march=native
-std=gnu++0x (NOT c++0x, that doesn't work).
-lintl first in link line
-lws2_32 last in line line

STK opcodes CMakeLists.txt change that I have pushed:

Change:

            make_plugin(stk-ops stkOpcodes.cpp "stk")

To:

            make_plugin(stk-ops stkOpcodes.cpp ${STK_LIBRARY})

Regards,
Mike

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Which functions?

VL


On 17 Mar 2013, at 19:32, Michael Gogins  wrote:

> For Csound 6 with MinGW 4.6.2 on Windows 8 Premium Home Edition, I
> have built Csound64, the Csound library, the STK opcodes, CsoundAC,
> and the Python and Lua interfaces for both Csound and CsoundAC.
> 
> Changes to sources include restoring #fdef'd API functions back into
> the CSOUND struct, because some of the functions are used by plugins
> (such as the FLTK opcodes) that I am building. The motive for putting
> these functions into the struct is not just to mimic a class, but to
> remove the necessity for plugins to link with the Csound library.
> Please do not remove these API functions from the struct unless you
> also fix dependent plugins not to need them.
> 
> I made other minor changes as required to satisfy MinGW 4.6.2. One was
> to #include  not , this is now standard.
> 
> C++ compiler flags that I have not pushed yet:
> 
> -include cmath (fixes bug introduced by SWIG and Python clashing with
> std namespace for hypot)
> -march=native
> -std=gnu++0x (NOT c++0x, that doesn't work).
> -lintl first in link line
> -lws2_32 last in line line
> 
> STK opcodes CMakeLists.txt change that I have pushed:
> 
> Change:
> 
>            make_plugin(stk-ops stkOpcodes.cpp "stk")
> 
> To:
> 
>            make_plugin(stk-ops stkOpcodes.cpp ${STK_LIBRARY})
> 
> Regards,
> Mike
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I don't understand why we would need, for instance:

 CSOUND *(*Create)(void *hostData);
    TREE *(*ParseOrc)(CSOUND *, char *str);
    int (*CompileTree)(CSOUND *, TREE *root);
    int (*CompileOrc)(CSOUND *, char *str);
    int (*ReadScore)(CSOUND *, char *str);
    int (*Compile)(CSOUND *, int argc, char **argv);
    int (*Start)(CSOUND *);
    int (*Perform)(CSOUND *);
    int (*PerformBuffer)(CSOUND *);
    int (*Cleanup)(CSOUND *);
    void (*Reset)(CSOUND *);
    void (*Destroy)(CSOUND *);

Plugins should not be creating, parsing, compiling, read socre, starting csound,  perform, performBuffer, cleanup, reset, destroy?
Or should they?

Victor
On 17 Mar 2013, at 19:32, Michael Gogins wrote:

> Changes to sources include restoring #fdef'd API functions back into
> the CSOUND struct, because some of the functions are used by plugins
> (such as the FLTK opcodes) that I am building. The motive for putting
> these functions into the struct is not just to mimic a class, but to
> remove the necessity for plugins to link with the Csound library.
> Please do not remove these API functions from the struct unless you
> also fix dependent plugins not to need them.

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




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Why  would a Csound developer want to determine what clients of the
API might do? It is impossible to know these things in advance.

I think it is better to give clients of the API all powers available,
until it proves harmful, instead of giving them only what is thought
likely to be useful, until that proves limiting... as it always does.

As for putting these functions into the CSOUND struct, it is simpler
to put them all in than to exclude some.

A use case can be made for creating new instances of Csound from
within Csound, for example, using Csound as a message broker for
distributed renderings of pieces. But I'm afraid mentioning specific
cases like this will only distract from my point, which is that we
should be exposing power without necessarily knowing how it is going
to be used.

Best,
Mike

On Sun, Mar 17, 2013 at 3:48 PM, Victor Lazzarini
 wrote:
> I don't understand why we would need, for instance:
>
>  CSOUND *(*Create)(void *hostData);
>     TREE *(*ParseOrc)(CSOUND *, char *str);
>     int (*CompileTree)(CSOUND *, TREE *root);
>     int (*CompileOrc)(CSOUND *, char *str);
>     int (*ReadScore)(CSOUND *, char *str);
>     int (*Compile)(CSOUND *, int argc, char **argv);
>     int (*Start)(CSOUND *);
>     int (*Perform)(CSOUND *);
>     int (*PerformBuffer)(CSOUND *);
>     int (*Cleanup)(CSOUND *);
>     void (*Reset)(CSOUND *);
>     void (*Destroy)(CSOUND *);
>
> Plugins should not be creating, parsing, compiling, read socre, starting csound,  perform, performBuffer, cleanup, reset, destroy?
> Or should they?
>
> Victor
> On 17 Mar 2013, at 19:32, Michael Gogins wrote:
>
>> Changes to sources include restoring #fdef'd API functions back into
>> the CSOUND struct, because some of the functions are used by plugins
>> (such as the FLTK opcodes) that I am building. The motive for putting
>> these functions into the struct is not just to mimic a class, but to
>> remove the necessity for plugins to link with the Csound library.
>> Please do not remove these API functions from the struct unless you
>> also fix dependent plugins not to need them.
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> 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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The reason for removing these is to make access for hosts limited to the public API in csound.h and csound.hpp. 
I would argue that it can be confusing for anyone to realise that there is csoundPeform() and also csound->Perform(), 
plus csound->Perform() in C++.  There is no real reason to have Perform() in the CSOUND structure. In Csound 6, we have 
attempted to simplify and streamline CSOUND, although we have not managed to completely do it. 
Putting these functions back goes against this.

To preserve functionality, we can maintain a minimum of these that have been used. But it would be better not to encourage
further use that can possibly cause confusion in the future.

Victor
On 17 Mar 2013, at 19:59, Michael Gogins wrote:

> Why  would a Csound developer want to determine what clients of the
> API might do? It is impossible to know these things in advance.
> 
> I think it is better to give clients of the API all powers available,
> until it proves harmful, instead of giving them only what is thought
> likely to be useful, until that proves limiting... as it always does.
> 
> As for putting these functions into the CSOUND struct, it is simpler
> to put them all in than to exclude some.
> 
> A use case can be made for creating new instances of Csound from
> within Csound, for example, using Csound as a message broker for
> distributed renderings of pieces. But I'm afraid mentioning specific
> cases like this will only distract from my point, which is that we
> should be exposing power without necessarily knowing how it is going
> to be used.
> 
> Best,
> Mike
> 
> On Sun, Mar 17, 2013 at 3:48 PM, Victor Lazzarini
>  wrote:
>> I don't understand why we would need, for instance:
>> 
>> CSOUND *(*Create)(void *hostData);
>>    TREE *(*ParseOrc)(CSOUND *, char *str);
>>    int (*CompileTree)(CSOUND *, TREE *root);
>>    int (*CompileOrc)(CSOUND *, char *str);
>>    int (*ReadScore)(CSOUND *, char *str);
>>    int (*Compile)(CSOUND *, int argc, char **argv);
>>    int (*Start)(CSOUND *);
>>    int (*Perform)(CSOUND *);
>>    int (*PerformBuffer)(CSOUND *);
>>    int (*Cleanup)(CSOUND *);
>>    void (*Reset)(CSOUND *);
>>    void (*Destroy)(CSOUND *);
>> 
>> Plugins should not be creating, parsing, compiling, read socre, starting csound,  perform, performBuffer, cleanup, reset, destroy?
>> Or should they?
>> 
>> Victor
>> On 17 Mar 2013, at 19:32, Michael Gogins wrote:
>> 
>>> Changes to sources include restoring #fdef'd API functions back into
>>> the CSOUND struct, because some of the functions are used by plugins
>>> (such as the FLTK opcodes) that I am building. The motive for putting
>>> these functions into the struct is not just to mimic a class, but to
>>> remove the necessity for plugins to link with the Csound library.
>>> Please do not remove these API functions from the struct unless you
>>> also fix dependent plugins not to need them.
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> 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
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> 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




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>
> I made other minor changes as required to satisfy MinGW 4.6.2. One was
> to #include  not , this is now standard.
>

I cannot find winsock.h anywhere in the sourses



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree with Victor. It is a generally understood principle of plugins 
that they are as much as possible host-agnostic if not entirely 
host-ignorant, and in particular they have no business taking control of 
the host in anything other than severely limited ways. They should be 
able to query the host for information, but that is about all. They 
would not be aware of the presence of other plugins either.

I would suggest, for example, that a plugin calling Destroy() is a very 
bad idea (as bad as directly calling abort()). One host may entertain 
umpteen plugins, and they manifestly cannot all take charge of the host 
at the same time in conflicting ways. To the plugin, the host should be 
in principle a read-only object.

Richard Dobso
n

On 17/03/2013 19:59, Michael Gogins wrote:
> Why  would a Csound developer want to determine what clients of the
> API might do? It is impossible to know these things in advance.
>
> I think it is better to give clients of the API all powers available,
> until it proves harmful, instead of giving them only what is thought
> likely to be useful, until that proves limiting... as it always does.
>
> As for putting these functions into the CSOUND struct, it is simpler
> to put them all in than to exclude some.
>
> A use case can be made for creating new instances of Csound from
> within Csound, for example, using Csound as a message broker for
> distributed renderings of pieces. But I'm afraid mentioning specific
> cases like this will only distract from my point, which is that we
> should be exposing power without necessarily knowing how it is going
> to be used.
>
> Best,
> Mike
>
..

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yes, this is one of the things I'm mindful of here. In fact, we have been trying to hide some of the things like sr, ksmps etc and
make it accessible only through the Get...() interface.

Regarding the CSOUND structure functions, I would prefer if functions are only put back on a case-by-case basis, when a
given plugin does not build. As far as I can see at the moment, by checking c and cpp files, all plugins should build with the
current CSOUND members.

Victor

On 17 Mar 2013, at 20:22, Richard Dobson wrote:

> I agree with Victor. It is a generally understood principle of plugins 
> that they are as much as possible host-agnostic if not entirely 
> host-ignorant, and in particular they have no business taking control of 
> the host in anything other than severely limited ways. They should be 
> able to query the host for information, but that is about all. They 
> would not be aware of the presence of other plugins either.
> 
> I would suggest, for example, that a plugin calling Destroy() is a very 
> bad idea (as bad as directly calling abort()). One host may entertain 
> umpteen plugins, and they manifestly cannot all take charge of the host 
> at the same time in conflicting ways. To the plugin, the host should be 
> in principle a read-only object.
> 
> Richard Dobso
> n
> 
> On 17/03/2013 19:59, Michael Gogins wrote:
>> Why  would a Csound developer want to determine what clients of the
>> API might do? It is impossible to know these things in advance.
>> 
>> I think it is better to give clients of the API all powers available,
>> until it proves harmful, instead of giving them only what is thought
>> likely to be useful, until that proves limiting... as it always does.
>> 
>> As for putting these functions into the CSOUND struct, it is simpler
>> to put them all in than to exclude some.
>> 
>> A use case can be made for creating new instances of Csound from
>> within Csound, for example, using Csound as a message broker for
>> distributed renderings of pieces. But I'm afraid mentioning specific
>> cases like this will only distract from my point, which is that we
>> should be exposing power without necessarily knowing how it is going
>> to be used.
>> 
>> Best,
>> Mike
>> 
> ..
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> 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




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree completely with encapsulating data in the API behind functions.

I'm also in favor of simplifying the API and I agree that it is
confusing to have multiple names for the same thing. If I had
determined the course of the API in all details, there would have been
one COM like C++ interface used by all clients of Csound, internal and
external.

I'm fine with changing things until we get it right also, I just
needed to put this stuff back to I get the things I want to play with
in Csound 6 built and running.

However, I want to repeat: Don't let us Csound developers think we
know in advance what the users are going to want to do with the API. I
don't think we should be distinguishing between internal and external
clients of the API, and I don't think we should be limiting what goes
into the API.

This, after all, is the whole point of exposing the parse tree, etc.

Let the power out of the box.

Regards,
Mike

On Sun, Mar 17, 2013 at 4:39 PM, Victor Lazzarini
 wrote:
> yes, this is one of the things I'm mindful of here. In fact, we have been trying to hide some of the things like sr, ksmps etc and
> make it accessible only through the Get...() interface.
>
> Regarding the CSOUND structure functions, I would prefer if functions are only put back on a case-by-case basis, when a
> given plugin does not build. As far as I can see at the moment, by checking c and cpp files, all plugins should build with the
> current CSOUND members.
>
> Victor
>
> On 17 Mar 2013, at 20:22, Richard Dobson wrote:
>
>> I agree with Victor. It is a generally understood principle of plugins
>> that they are as much as possible host-agnostic if not entirely
>> host-ignorant, and in particular they have no business taking control of
>> the host in anything other than severely limited ways. They should be
>> able to query the host for information, but that is about all. They
>> would not be aware of the presence of other plugins either.
>>
>> I would suggest, for example, that a plugin calling Destroy() is a very
>> bad idea (as bad as directly calling abort()). One host may entertain
>> umpteen plugins, and they manifestly cannot all take charge of the host
>> at the same time in conflicting ways. To the plugin, the host should be
>> in principle a read-only object.
>>
>> Richard Dobso
>> n
>>
>> On 17/03/2013 19:59, Michael Gogins wrote:
>>> Why  would a Csound developer want to determine what clients of the
>>> API might do? It is impossible to know these things in advance.
>>>
>>> I think it is better to give clients of the API all powers available,
>>> until it proves harmful, instead of giving them only what is thought
>>> likely to be useful, until that proves limiting... as it always does.
>>>
>>> As for putting these functions into the CSOUND struct, it is simpler
>>> to put them all in than to exclude some.
>>>
>>> A use case can be made for creating new instances of Csound from
>>> within Csound, for example, using Csound as a message broker for
>>> distributed renderings of pieces. But I'm afraid mentioning specific
>>> cases like this will only distract from my point, which is that we
>>> should be exposing power without necessarily knowing how it is going
>>> to be used.
>>>
>>> Best,
>>> Mike
>>>
>> ..
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> 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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree with you there, I am not disputing this. I think we need to make the API as flexible and
wide-ranging as possible. 

My concern is to try to make the library more robust, and that is what have been guiding us in
hiding and removing some things from the CSOUND struct. 

On 17 Mar 2013, at 20:52, Michael Gogins wrote:

> However, I want to repeat: Don't let us Csound developers think we
> know in advance what the users are going to want to do with the API. 


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




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net