Hi Tito,

How are the initial messages generated by csoundPreCompile now managed
(Csound version, etc.)? Will they be passed when the Csound engine
starts running?

Cheers,
Andrés

On Fri, Apr 27, 2012 at 9:51 AM, Tito Latini  wrote:
> I have the changes to remove csoundPreCompile.
>
> The code in `csoundPreCompile' is necessary only in `csoundReset'
> because `csoundCreate' calls `csoundReset'.
>
> `csoundDestroy' calls `csoundReset', so I renamed the old
> `csoundReset' in `csoundReset_' and `csoundDestroy' calls it.
>
> The body of the new `csoundReset' is
>
>    csoundReset_(csound);
>    ... the old csoundPreCompile code ...
>
> I have replaced the errors+return in the old csoundPreCompile code
> with a provisional `csound->Die(csound, "...")', because the return
> type of `csoundReset' is "void".
>
> Updated the following files:
>
>  frontends/CsoundVST/CsoundVST.cpp
>  frontends/csladspa/csladspa.cpp
>  frontends/csoundapi_tilde/csoundapi_tilde.c
>  frontends/flcsound/synthesizer.cpp
>  frontends/fltk_gui/CsoundGUIMain.cpp
>  frontends/fltk_gui/CsoundUtility.cpp
>  frontends/tclcsound/commands.c
>  frontends/winsound/main.cxx
>  util/utilmain.h
>  util/pvl_main.c
>  util1/cscore/cscore_main.c
>  util1/sortex/xmain.c
>  util1/sortex/smain.c
>  android/CsoundAndroid/src/com/csounds/CsoundObj.java
>  android/CsoundAndroid/jni/AndroidCsound.cpp
>
>
> Let me know if I can apply the change or if it collides with your work.
>
> 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
https://lists.sourceforge.net/list

Hi,

OK, good. So you would need to register the message callbacks before
creating Csound? I seem to remember you couldn't do this with the
current API, but maybe I'm wrong...

Cheers,
Andrés

On Fri, Apr 27, 2012 at 10:21 AM, Tito Latini  wrote:
> During the creation of the instance with `csoundCreate', because it
> calls `csoundReset' that contains the code of the old `csoundPreCompile'.
>
> tito
>
> On Fri, Apr 27, 2012 at 10:22:42AM +0100, Andres Cabrera wrote:
>> Hi Tito,
>>
>> How are the initial messages generated by csoundPreCompile now managed
>> (Csound version, etc.)? Will they be passed when the Csound engine
>> starts running?
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Apr 27, 2012 at 9:51 AM, Tito Latini  wrote:
>> > I have the changes to remove csoundPreCompile.
>> >
>> > The code in `csoundPreCompile' is necessary only in `csoundReset'
>> > because `csoundCreate' calls `csoundReset'.
>> >
>> > `csoundDestroy' calls `csoundReset', so I renamed the old
>> > `csoundReset' in `csoundReset_' and `csoundDestroy' calls it.
>> >
>> > The body of the new `csoundReset' is
>> >
>> >    csoundReset_(csound);
>> >    ... the old csoundPreCompile code ...
>> >
>> > I have replaced the errors+return in the old csoundPreCompile code
>> > with a provisional `csound->Die(csound, "...")', because the return
>> > type of `csoundReset' is "void".
>> >
>> > Updated the following files:
>> >
>> >  frontends/CsoundVST/CsoundVST.cpp
>> >  frontends/csladspa/csladspa.cpp
>> >  frontends/csoundapi_tilde/csoundapi_tilde.c
>> >  frontends/flcsound/synthesizer.cpp
>> >  frontends/fltk_gui/CsoundGUIMain.cpp
>> >  frontends/fltk_gui/CsoundUtility.cpp
>> >  frontends/tclcsound/commands.c
>> >  frontends/winsound/main.cxx
>> >  util/utilmain.h
>> >  util/pvl_main.c
>> >  util1/cscore/cscore_main.c
>> >  util1/sortex/xmain.c
>> >  util1/sortex/smain.c
>> >  android/CsoundAndroid/src/com/csounds/CsoundObj.java
>> >  android/CsoundAndroid/jni/AndroidCsound.cpp
>> >
>> >
>> > Let me know if I can apply the change or if it collides with your work.
>> >
>> > 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
>> 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://list

Nice. I like the way it looks.

Cheers,
Andrés

On Fri, Apr 27, 2012 at 10:52 AM, Tito Latini  wrote:
> Besides, I have moved `csoundLoadExternals' and `csoundInitModules'
> from `csoundCompile' to `csoundReset' (called by `csoundCreate').
> We can these sequences (tested):
>
>  1)
>     csoundCreate
>     csoundCompile
>
>  2)
>     csoundCreate
>     csoundCompileOrc    (orc from string)
>     csoundReadScore     (sco from string)
>
>  3)
>     csoundCreate
>     csoundParseOrc      (orc from string, return a TREE ptr)
>     csoundCompileTree
>     csoundReadScore
>
> 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
https://lists.sourceforge.net/lists/listinfo/

But then wouldn't that mean that the initial messages are not passed
to the callback?

Cheers,
Andrés

On Fri, Apr 27, 2012 at 11:09 AM, Tito Latini  wrote:
>> OK, good. So you would need to register the message callbacks before
>> creating Csound? I seem to remember you couldn't do this with the
>> current API, but maybe I'm wrong...
>
> csound = csoundCreate(0);
> csoundSetMessageCallback(csound, ...);
> ...
>
> ------------------------------------------------------------------------------
> 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

+1  - with the seemingly global surge in the mission of teaching 
everyone to program (codecademy, RaspberryPi et al), Csound has the 
potential to be an extra-ordinary educational resource quite apart from 
its actual functionality. UK exam boards (and it seems most CS teachers) 
are more or less allergic to C and C++ (C has recently been removed from 
one list of "approved" languages, by one examining board in the UK), 
while they are dead keen on Java and Python. So anything that can be 
done in Csound to make the code as clear, readable and self-documenting 
as possible has to be a good thing. Doxygen, needless to say, will not 
cut it!


Richard Dobson



On 27/04/2012 13:55, Dr. Richard Boulanger wrote:
> +1 for the most clear and intuitive and unambiguous naming.
>
> PS. Hopefully? All of these details descriptions of how computers work,
> how compilers work and how Csound works will
> hopefully end up in the new Csound Book, the Floss manual, the Csound
> Manual, the Csound Journal... and not
> just the email archive. They have been incredibly informative and
> enlightening.
..

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

How about sending the initial batch of messages when the callback is set?

This might also be an interesting idea to remove the message storing
capabilities currently available in the API, which are limited and
cumbersome. Maybe Csound could always store the messages which could
be queried with an API call, or a callback could be set to process
those messages. I'm not sure if there are performance or concurrency
implications, but this would actually be nice for batch running where
there is no need to set a message callback but just call an API
function to get all the messages produced by Csound.

Cheers,
Andrés

On Fri, Apr 27, 2012 at 11:52 AM, Tito Latini  wrote:
> Another possibility is a function API to set `csoundDefaultMessageCallback'.
>
>  csoundSetDefaultMessageCallback(msgCallback)
>  csoundCreate(0)
>  ...
>
> tito
>
> On Fri, Apr 27, 2012 at 06:54:45AM -0400, Michael Gogins wrote:
>> My comments:
>>
>> (1) None of these functions should cause Csound to actually exit the
>> process, unless something happens in them that actually kills Csound. This
>> is to accomodate hosts that may fix up things up or allow the user to fix
>> things up and try again. If Die does not cause Csound to actually exit the
>> process, it should be renamed.
>>
>> (2) Could the need for this PreCompile function be avoided by re-ordering
>> the compile and reset steps, so that callbacks can simply be set after
>> csoundCreate and before csoundCompile?
>>
>> (3) If not, certainly setting callbacks etc. before compiling does seem to
>> be vital. Rename the function to csoundBindCallbacks or csoundInitialize or
>> something that is more indicative of what it actually does. What else, in
>> fact, does it do?
>>
>> Finally, names are extremely important. We who have some experience with
>> the code are one thing. People with less knowledge who need to use the API
>> are another thing. The names should be as unambiguous, clear, and
>> indicative of function as possible, consistent with being reasonably short.
>> Actually, even the people who think they know the code will be benefit from
>> renaming things as clearly as possible. Unclear names hide design problems.
>>
>> Regards,
>> Mike
>>
>> On Fri, Apr 27, 2012 at 6:29 AM, Tito Latini  wrote:
>>
>> > Now I see 2 solutions:
>> >
>> >  1. csoundCreate(hostData, msgCallback)
>> >  2. csoundCreate + csoundPreCompile
>> >
>> > 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
>> 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:

At my community college, there is a computer architecture class that
requires calculus. Then and only then do students learn C (and as far
as I know, they only briefly touch on it; I have never taken the
course myself.)

On 4/27/12, Andres Cabrera  wrote:
> Hi,
>
> How about sending the initial batch of messages when the callback is set?
>
> This might also be an interesting idea to remove the message storing
> capabilities currently available in the API, which are limited and
> cumbersome. Maybe Csound could always store the messages which could
> be queried with an API call, or a callback could be set to process
> those messages. I'm not sure if there are performance or concurrency
> implications, but this would actually be nice for batch running where
> there is no need to set a message callback but just call an API
> function to get all the messages produced by Csound.
>
> Cheers,
> Andrés
>
> On Fri, Apr 27, 2012 at 11:52 AM, Tito Latini  wrote:
>> Another possibility is a function API to set
>> `csoundDefaultMessageCallback'.
>>
>>  csoundSetDefaultMessageCallback(msgCallback)
>>  csoundCreate(0)
>>  ...
>>
>> tito
>>
>> On Fri, Apr 27, 2012 at 06:54:45AM -0400, Michael Gogins wrote:
>>> My comments:
>>>
>>> (1) None of these functions should cause Csound to actually exit the
>>> process, unless something happens in them that actually kills Csound.
>>> This
>>> is to accomodate hosts that may fix up things up or allow the user to fix
>>> things up and try again. If Die does not cause Csound to actually exit
>>> the
>>> process, it should be renamed.
>>>
>>> (2) Could the need for this PreCompile function be avoided by re-ordering
>>> the compile and reset steps, so that callbacks can simply be set after
>>> csoundCreate and before csoundCompile?
>>>
>>> (3) If not, certainly setting callbacks etc. before compiling does seem
>>> to
>>> be vital. Rename the function to csoundBindCallbacks or csoundInitialize
>>> or
>>> something that is more indicative of what it actually does. What else, in
>>> fact, does it do?
>>>
>>> Finally, names are extremely important. We who have some experience with
>>> the code are one thing. People with less knowledge who need to use the
>>> API
>>> are another thing. The names should be as unambiguous, clear, and
>>> indicative of function as possible, consistent with being reasonably
>>> short.
>>> Actually, even the people who think they know the code will be benefit
>>> from
>>> renaming things as clearly as possible. Unclear names hide design
>>> problems.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Fri, Apr 27, 2012 at 6:29 AM, Tito Latini 
>>> wrote:
>>>
>>> > Now I see 2 solutions:
>>> >
>>> >  1. csoundCreate(hostData, msgCallback)
>>> >  2. csoundCreate + csoundPreCompile
>>> >
>>> > 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
>>> 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

Also +1. I'm personally in favor of making everything, including the
code, as clear, readable and self-documenting as possibly. Even
orchestra instrs and UDOs would benefit greatly if they supported a
system for autodocs.

On Fri, Apr 27, 2012 at 6:18 AM, Richard Dobson
 wrote:
> +1  - with the seemingly global surge in the mission of teaching
> everyone to program (codecademy, RaspberryPi et al), Csound has the
> potential to be an extra-ordinary educational resource quite apart from
> its actual functionality. UK exam boards (and it seems most CS teachers)
> are more or less allergic to C and C++ (C has recently been removed from
> one list of "approved" languages, by one examining board in the UK),
> while they are dead keen on Java and Python. So anything that can be
> done in Csound to make the code as clear, readable and self-documenting
> as possible has to be a good thing. Doxygen, needless to say, will not
> cut it!
>
>
> Richard Dobson
>
>
>
> On 27/04/2012 13:55, Dr. Richard Boulanger wrote:
>> +1 for the most clear and intuitive and unambiguous naming.
>>
>> PS. Hopefully? All of these details descriptions of how computers work,
>> how compilers work and how Csound works will
>> hopefully end up in the new Csound Book, the Floss manual, the Csound
>> Manual, the Csound Journal... and not
>> just the email archive. They have been incredibly informative and
>> enlightening.
> ..
>
> ------------------------------------------------------------------------------
> 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



-- 
codehop.com | #code #art #music

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

Hi,

I've been thinking a lot about this lately, and how about setting the
callback when csound is created?

csound = csoundCreate(0, msg_callback);

I'm thinking about reducing the API, so wherever we can remove a
function, I think that's a good thing.
We could also remove the callback setter function (setting the
callback would only be allowed when creating csound), and if a
callback is not set, the internal message buffer mechanism is
activated:

So the functions:
1779 	void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int toStdOut);
1805 	void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
would go from the public API

and the functions:
1784 	PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
1790 	int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
1795 	void PUBLIC csoundPopFirstMessage(CSOUND *csound);
1800 	int PUBLIC csoundGetMessageCnt(CSOUND *csound);

Would only work if no callback has been set. (These four functions
could even be trimmed and cleaned up to make them more consice).

Thoughts?

Cheers,
Andrés



On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini  wrote:
> Applied:
>  - removed `csoundPreCompile'
>  - added `csoundSetDefaultMessageCallback'
>
> Tested with:
>
> static void msg_callback(CSOUND *csound,
>                         int attr, const char *format, va_list args)
> {
>    (void) csound;
>    printf("====================");
>    vfprintf(stderr, format, args);
> }
>
> csoundSetDefaultMessageCallback(msg_callback);
> csound = csoundCreate(0);
> ...
>
> 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
https://lists.sourcefo

I presume this idea is solely for messages; I guess it does not make sense for other callbacks, or does it?
I am thinking this:

typedef struct csound_cbs {
...
} CSOUND_CALLBACKS;

CSOUND *csoundCreate(void *userData, CSOUND_CALLBACKS *p)

but that means limiting callback setting to newly created instances. Maybe not a good idea.

Victor

On 30 Apr 2012, at 08:43, Andres Cabrera wrote:

> Hi,
> 
> I've been thinking a lot about this lately, and how about setting the
> callback when csound is created?
> 
> csound = csoundCreate(0, msg_callback);
> 
> I'm thinking about reducing the API, so wherever we can remove a
> function, I think that's a good thing.
> We could also remove the callback setter function (setting the
> callback would only be allowed when creating csound), and if a
> callback is not set, the internal message buffer mechanism is
> activated:
> 
> So the functions:
> 1779 	void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int toStdOut);
> 1805 	void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
> would go from the public API
> 
> and the functions:
> 1784 	PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
> 1790 	int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
> 1795 	void PUBLIC csoundPopFirstMessage(CSOUND *csound);
> 1800 	int PUBLIC csoundGetMessageCnt(CSOUND *csound);
> 
> Would only work if no callback has been set. (These four functions
> could even be trimmed and cleaned up to make them more consice).
> 
> Thoughts?
> 
> Cheers,
> Andrés
> 
> 
> 
> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini  wrote:
>> Applied:
>>  - removed `csoundPreCompile'
>>  - added `csoundSetDefaultMessageCallback'
>> 
>> Tested with:
>> 
>> static void msg_callback(CSOUND *csound,
>>                         int attr, const char *format, va_list args)
>> {
>>    (void) csound;
>>    printf("====================");
>>    vfprintf(stderr, format, args);
>> }
>> 
>> csoundSetDefaultMessageCallback(msg_callback);
>> csound = csoundCreate(0);
>> ...
>> 
>> 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
> 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

I think it should only be for messages, as other callbacks would be
less used, and could have their own callback setter. But it makes me
think. Would a user want to change any of the callbacks for a csound
instance? If it only makes sense to set them once, maybe it would also
make sense to have them all as an argument to the csoundCreate
function.

But in any case, I think the API might look cleaner to most users with
my proposal. My only concern is that what I propose is considered bad
practice or would be too unusual for most users.

Cheers,
Andrés

On Mon, Apr 30, 2012 at 11:23 AM, Victor Lazzarini
 wrote:
> I presume this idea is solely for messages; I guess it does not make sense for other callbacks, or does it?
> I am thinking this:
>
> typedef struct csound_cbs {
> ...
> } CSOUND_CALLBACKS;
>
> CSOUND *csoundCreate(void *userData, CSOUND_CALLBACKS *p)
>
> but that means limiting callback setting to newly created instances. Maybe not a good idea.
>
> Victor
>
> On 30 Apr 2012, at 08:43, Andres Cabrera wrote:
>
>> Hi,
>>
>> I've been thinking a lot about this lately, and how about setting the
>> callback when csound is created?
>>
>> csound = csoundCreate(0, msg_callback);
>>
>> I'm thinking about reducing the API, so wherever we can remove a
>> function, I think that's a good thing.
>> We could also remove the callback setter function (setting the
>> callback would only be allowed when creating csound), and if a
>> callback is not set, the internal message buffer mechanism is
>> activated:
>>
>> So the functions:
>> 1779  void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int toStdOut);
>> 1805  void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
>> would go from the public API
>>
>> and the functions:
>> 1784  PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
>> 1790  int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
>> 1795  void PUBLIC csoundPopFirstMessage(CSOUND *csound);
>> 1800  int PUBLIC csoundGetMessageCnt(CSOUND *csound);
>>
>> Would only work if no callback has been set. (These four functions
>> could even be trimmed and cleaned up to make them more consice).
>>
>> Thoughts?
>>
>> Cheers,
>> Andrés
>>
>>
>>
>> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini  wrote:
>>> Applied:
>>>  - removed `csoundPreCompile'
>>>  - added `csoundSetDefaultMessageCallback'
>>>
>>> Tested with:
>>>
>>> static void msg_callback(CSOUND *csound,
>>>                         int attr, const char *format, va_list args)
>>> {
>>>    (void) csound;
>>>    printf("====================");
>>>    vfprintf(stderr, format, args);
>>> }
>>>
>>> csoundSetDefaultMessageCallback(msg_callback);
>>> csound = csoundCreate(0);
>>> ...
>>>
>>> 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
>> 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
> 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/list

Interesting.  Maybe all the message functions be reduced to ...
CSOUND *csoundCreate(void *hostData, void (*messageCallback_)(CSOUND
*csound, int attribute, const char *message));
int csoundSetMessageCallback(CSOUND *, void (*messageCallback_)(CSOUND
*csound, int attribute, const char *message));

Then make messages go to stdout only if messageCallback_ is zero.

~ andy.f



On Mon, Apr 30, 2012 at 3:43 AM, Andres Cabrera  wrote:
> Hi,
>
> I've been thinking a lot about this lately, and how about setting the
> callback when csound is created?
>
> csound = csoundCreate(0, msg_callback);
>
> I'm thinking about reducing the API, so wherever we can remove a
> function, I think that's a good thing.
> We could also remove the callback setter function (setting the
> callback would only be allowed when creating csound), and if a
> callback is not set, the internal message buffer mechanism is
> activated:
>
> So the functions:
> 1779    void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int toStdOut);
> 1805    void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
> would go from the public API
>
> and the functions:
> 1784    PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
> 1790    int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
> 1795    void PUBLIC csoundPopFirstMessage(CSOUND *csound);
> 1800    int PUBLIC csoundGetMessageCnt(CSOUND *csound);
>
> Would only work if no callback has been set. (These four functions
> could even be trimmed and cleaned up to make them more consice).
>
> Thoughts?
>
> Cheers,
> Andrés
>
>
>
> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini  wrote:
>> Applied:
>>  - removed `csoundPreCompile'
>>  - added `csoundSetDefaultMessageCallback'
>>
>> Tested with:
>>
>> static void msg_callback(CSOUND *csound,
>>                         int attr, const char *format, va_list args)
>> {
>>    (void) csound;
>>    printf("====================");
>>    vfprintf(stderr, format, args);
>> }
>>
>> csoundSetDefaultMessageCallback(msg_callback);
>> csound = csoundCreate(0);
>> ...
>>
>> 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
> 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

That is another idea. Getting rid of the internal message buffer
completely and just sending to stdout when no callback is set.

Cheers,
Andrés

On Mon, Apr 30, 2012 at 1:05 PM, andy fillebrown
 wrote:
> Interesting.  Maybe all the message functions be reduced to ...
> CSOUND *csoundCreate(void *hostData, void (*messageCallback_)(CSOUND
> *csound, int attribute, const char *message));
> int csoundSetMessageCallback(CSOUND *, void (*messageCallback_)(CSOUND
> *csound, int attribute, const char *message));
>
> Then make messages go to stdout only if messageCallback_ is zero.
>
> ~ andy.f
>
>
>
> On Mon, Apr 30, 2012 at 3:43 AM, Andres Cabrera  wrote:
>> Hi,
>>
>> I've been thinking a lot about this lately, and how about setting the
>> callback when csound is created?
>>
>> csound = csoundCreate(0, msg_callback);
>>
>> I'm thinking about reducing the API, so wherever we can remove a
>> function, I think that's a good thing.
>> We could also remove the callback setter function (setting the
>> callback would only be allowed when creating csound), and if a
>> callback is not set, the internal message buffer mechanism is
>> activated:
>>
>> So the functions:
>> 1779    void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int toStdOut);
>> 1805    void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
>> would go from the public API
>>
>> and the functions:
>> 1784    PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
>> 1790    int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
>> 1795    void PUBLIC csoundPopFirstMessage(CSOUND *csound);
>> 1800    int PUBLIC csoundGetMessageCnt(CSOUND *csound);
>>
>> Would only work if no callback has been set. (These four functions
>> could even be trimmed and cleaned up to make them more consice).
>>
>> Thoughts?
>>
>> Cheers,
>> Andrés
>>
>>
>>
>> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini  wrote:
>>> Applied:
>>>  - removed `csoundPreCompile'
>>>  - added `csoundSetDefaultMessageCallback'
>>>
>>> Tested with:
>>>
>>> static void msg_callback(CSOUND *csound,
>>>                         int attr, const char *format, va_list args)
>>> {
>>>    (void) csound;
>>>    printf("====================");
>>>    vfprintf(stderr, format, args);
>>> }
>>>
>>> csoundSetDefaultMessageCallback(msg_callback);
>>> csound = csoundCreate(0);
>>> ...
>>>
>>> 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
>> 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://l

Thinking more on this, the message callback could be set before
csoundCreate is called.  This would remove the need to set it in
csoundCreate.

~ af



On Mon, Apr 30, 2012 at 8:05 AM, andy fillebrown
 wrote:
> Interesting.  Maybe all the message functions be reduced to ...
> CSOUND *csoundCreate(void *hostData, void (*messageCallback_)(CSOUND
> *csound, int attribute, const char *message));
> int csoundSetMessageCallback(CSOUND *, void (*messageCallback_)(CSOUND
> *csound, int attribute, const char *message));
>
> Then make messages go to stdout only if messageCallback_ is zero.
>
> ~ andy.f
>
>
>
> On Mon, Apr 30, 2012 at 3:43 AM, Andres Cabrera  wrote:
>> Hi,
>>
>> I've been thinking a lot about this lately, and how about setting the
>> callback when csound is created?
>>
>> csound = csoundCreate(0, msg_callback);
>>
>> I'm thinking about reducing the API, so wherever we can remove a
>> function, I think that's a good thing.
>> We could also remove the callback setter function (setting the
>> callback would only be allowed when creating csound), and if a
>> callback is not set, the internal message buffer mechanism is
>> activated:
>>
>> So the functions:
>> 1779    void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int toStdOut);
>> 1805    void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
>> would go from the public API
>>
>> and the functions:
>> 1784    PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
>> 1790    int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
>> 1795    void PUBLIC csoundPopFirstMessage(CSOUND *csound);
>> 1800    int PUBLIC csoundGetMessageCnt(CSOUND *csound);
>>
>> Would only work if no callback has been set. (These four functions
>> could even be trimmed and cleaned up to make them more consice).
>>
>> Thoughts?
>>
>> Cheers,
>> Andrés
>>
>>
>>
>> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini  wrote:
>>> Applied:
>>>  - removed `csoundPreCompile'
>>>  - added `csoundSetDefaultMessageCallback'
>>>
>>> Tested with:
>>>
>>> static void msg_callback(CSOUND *csound,
>>>                         int attr, const char *format, va_list args)
>>> {
>>>    (void) csound;
>>>    printf("====================");
>>>    vfprintf(stderr, format, args);
>>> }
>>>
>>> csoundSetDefaultMessageCallback(msg_callback);
>>> csound = csoundCreate(0);
>>> ...
>>>
>>> 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
>> 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

Setting the message callback pointer before calling csoundCreate
doesn't mean the callback pointer has to be global.

static void (*currentMessageCallback)(
    CSOUND*, int, const char*) = 0;

void csoundSetMessageCallback(
    CSOUND *csound,
    void (*messageCallback_)(CSOUND*, int, const char*))
{
    if (csound)
        csound->messageCallback = messageCallback_;
    else
        currentMessageCallback = messageCallback_;
}

CSOUND *csoundCreate()
{
    CSOUND *csound = ...
    csound->messageCallback = currentMessageCallback;
}

That way the message callback can be set before or after the csound
instance is created.

~ andy.f



On Mon, Apr 30, 2012 at 9:08 AM, Michael Gogins
 wrote:
> No, no, and again no!  The message callback must be set per instance of
> Csound, not globally. Therefore, it must be called when an instance is
> created, or after.
>
> You must NOT assume that all instances of Csound in process will use the
> same message callback.
>
> A real-life example, which already exists and that I am not making up for
> the sake argument, that your proposal would kill:
>
> In Cubase I have one instance of CsoundVST on one track, another instance of
> CsoundVST on another track. Each instance logs its messages to its own
> individual message window.
>
> With your proposal you would see two Csound message windows in Cubase, but
> all the messages for both instances of Csound would go to one message
> window.
>
> Most confusing!
>
> Regards,
> Mike
>
>
> On Mon, Apr 30, 2012 at 8:37 AM, andy fillebrown 
> wrote:
>>
>> Thinking more on this, the message callback could be set before
>> csoundCreate is called.  This would remove the need to set it in
>> csoundCreate.
>>
>> ~ af
>>
>>
>>
>> On Mon, Apr 30, 2012 at 8:05 AM, andy fillebrown
>>  wrote:
>> > Interesting.  Maybe all the message functions be reduced to ...
>> > CSOUND *csoundCreate(void *hostData, void (*messageCallback_)(CSOUND
>> > *csound, int attribute, const char *message));
>> > int csoundSetMessageCallback(CSOUND *, void (*messageCallback_)(CSOUND
>> > *csound, int attribute, const char *message));
>> >
>> > Then make messages go to stdout only if messageCallback_ is zero.
>> >
>> > ~ andy.f
>> >
>> >
>> >
>> > On Mon, Apr 30, 2012 at 3:43 AM, Andres Cabrera 
>> > wrote:
>> >> Hi,
>> >>
>> >> I've been thinking a lot about this lately, and how about setting the
>> >> callback when csound is created?
>> >>
>> >> csound = csoundCreate(0, msg_callback);
>> >>
>> >> I'm thinking about reducing the API, so wherever we can remove a
>> >> function, I think that's a good thing.
>> >> We could also remove the callback setter function (setting the
>> >> callback would only be allowed when creating csound), and if a
>> >> callback is not set, the internal message buffer mechanism is
>> >> activated:
>> >>
>> >> So the functions:
>> >> 1779    void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int
>> >> toStdOut);
>> >> 1805    void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
>> >> would go from the public API
>> >>
>> >> and the functions:
>> >> 1784    PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
>> >> 1790    int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
>> >> 1795    void PUBLIC csoundPopFirstMessage(CSOUND *csound);
>> >> 1800    int PUBLIC csoundGetMessageCnt(CSOUND *csound);
>> >>
>> >> Would only work if no callback has been set. (These four functions
>> >> could even be trimmed and cleaned up to make them more consice).
>> >>
>> >> Thoughts?
>> >>
>> >> Cheers,
>> >> Andrés
>> >>
>> >>
>> >>
>> >> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini 
>> >> wrote:
>> >>> Applied:
>> >>>  - removed `csoundPreCompile'
>> >>>  - added `csoundSetDefaultMessageCallback'
>> >>>
>> >>> Tested with:
>> >>>
>> >>> static void msg_callback(CSOUND *csound,
>> >>>                         int attr, const char *format, va_list args)
>> >>> {
>> >>>    (void) csound;
>> >>>    printf("====================");
>> >>>    vfprintf(stderr, format, args);
>> >>> }
>> >>>
>> >>> csoundSetDefaultMessageCallback(msg_callback);
>> >>> csound = csoundCreate(0);
>> >>> ...
>> >>>
>> >>> 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
>> >> 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

Tito has already implemented a csoundSetDefaultMessageCallback, which
writes to a static variable. I think this might be a good solution,
although it does feel a bit odd setting the callback before creating
csound.

I do like the fact that create and initialize have been rolled into a
single function. Anything that reduces complexity and the size of the
API is good, I think. The only question is whether there is a need to
do anything between create and initialize that would warrant
separating them.

Cheers,
Andrés

On Mon, Apr 30, 2012 at 4:54 PM, andy fillebrown
 wrote:
> Setting the message callback pointer before calling csoundCreate
> doesn't mean the callback pointer has to be global.
>
> static void (*currentMessageCallback)(
>    CSOUND*, int, const char*) = 0;
>
> void csoundSetMessageCallback(
>    CSOUND *csound,
>    void (*messageCallback_)(CSOUND*, int, const char*))
> {
>    if (csound)
>        csound->messageCallback = messageCallback_;
>    else
>        currentMessageCallback = messageCallback_;
> }
>
> CSOUND *csoundCreate()
> {
>    CSOUND *csound = ...
>    csound->messageCallback = currentMessageCallback;
> }
>
> That way the message callback can be set before or after the csound
> instance is created.
>
> ~ andy.f
>
>
>
> On Mon, Apr 30, 2012 at 9:08 AM, Michael Gogins
>  wrote:
>> No, no, and again no!  The message callback must be set per instance of
>> Csound, not globally. Therefore, it must be called when an instance is
>> created, or after.
>>
>> You must NOT assume that all instances of Csound in process will use the
>> same message callback.
>>
>> A real-life example, which already exists and that I am not making up for
>> the sake argument, that your proposal would kill:
>>
>> In Cubase I have one instance of CsoundVST on one track, another instance of
>> CsoundVST on another track. Each instance logs its messages to its own
>> individual message window.
>>
>> With your proposal you would see two Csound message windows in Cubase, but
>> all the messages for both instances of Csound would go to one message
>> window.
>>
>> Most confusing!
>>
>> Regards,
>> Mike
>>
>>
>> On Mon, Apr 30, 2012 at 8:37 AM, andy fillebrown 
>> wrote:
>>>
>>> Thinking more on this, the message callback could be set before
>>> csoundCreate is called.  This would remove the need to set it in
>>> csoundCreate.
>>>
>>> ~ af
>>>
>>>
>>>
>>> On Mon, Apr 30, 2012 at 8:05 AM, andy fillebrown
>>>  wrote:
>>> > Interesting.  Maybe all the message functions be reduced to ...
>>> > CSOUND *csoundCreate(void *hostData, void (*messageCallback_)(CSOUND
>>> > *csound, int attribute, const char *message));
>>> > int csoundSetMessageCallback(CSOUND *, void (*messageCallback_)(CSOUND
>>> > *csound, int attribute, const char *message));
>>> >
>>> > Then make messages go to stdout only if messageCallback_ is zero.
>>> >
>>> > ~ andy.f
>>> >
>>> >
>>> >
>>> > On Mon, Apr 30, 2012 at 3:43 AM, Andres Cabrera 
>>> > wrote:
>>> >> Hi,
>>> >>
>>> >> I've been thinking a lot about this lately, and how about setting the
>>> >> callback when csound is created?
>>> >>
>>> >> csound = csoundCreate(0, msg_callback);
>>> >>
>>> >> I'm thinking about reducing the API, so wherever we can remove a
>>> >> function, I think that's a good thing.
>>> >> We could also remove the callback setter function (setting the
>>> >> callback would only be allowed when creating csound), and if a
>>> >> callback is not set, the internal message buffer mechanism is
>>> >> activated:
>>> >>
>>> >> So the functions:
>>> >> 1779    void PUBLIC csoundEnableMessageBuffer(CSOUND *csound, int
>>> >> toStdOut);
>>> >> 1805    void PUBLIC csoundDestroyMessageBuffer(CSOUND *csound);
>>> >> would go from the public API
>>> >>
>>> >> and the functions:
>>> >> 1784    PUBLIC const char* csoundGetFirstMessage(CSOUND *csound);
>>> >> 1790    int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
>>> >> 1795    void PUBLIC csoundPopFirstMessage(CSOUND *csound);
>>> >> 1800    int PUBLIC csoundGetMessageCnt(CSOUND *csound);
>>> >>
>>> >> Would only work if no callback has been set. (These four functions
>>> >> could even be trimmed and cleaned up to make them more consice).
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> Cheers,
>>> >> Andrés
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini 
>>> >> wrote:
>>> >>> Applied:
>>> >>>  - removed `csoundPreCompile'
>>> >>>  - added `csoundSetDefaultMessageCallback'
>>> >>>
>>> >>> Tested with:
>>> >>>
>>> >>> static void msg_callback(CSOUND *csound,
>>> >>>                         int attr, const char *format, va_list args)
>>> >>> {
>>> >>>    (void) csound;
>>> >>>    printf("====================");
>>> >>>    vfprintf(stderr, format, args);
>>> >>> }
>>> >>>
>>> >>> csoundSetDefaultMessageCallback(msg_callback);
>>> >>> csound = csoundCreate(0);
>>> >>> ...
>>> >>>
>>> >>> 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
>>> >> 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

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

On Mon, Apr 30, 2012 at 12:09 PM, Andres Cabrera  wrote:
> Tito has already implemented a csoundSetDefaultMessageCallback, which
> writes to a static variable. I think this might be a good solution,
> although it does feel a bit odd setting the callback before creating
> csound.

I missed Tito's post.  I don't see a need for two different message
callback functions, though.  Just pass NULL for the CSOUND pointer
parameter to set the callback as the default, imo.

~ andy.f

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

Yes, I think it's a matter of one or the other. I'm not partial to
either, because I don't have that much experience in API design, but
just wanted to keep the ball rolling.

Cheers,
Andrés

On Mon, Apr 30, 2012 at 5:25 PM, andy fillebrown
 wrote:
> On Mon, Apr 30, 2012 at 12:09 PM, Andres Cabrera  wrote:
>> Tito has already implemented a csoundSetDefaultMessageCallback, which
>> writes to a static variable. I think this might be a good solution,
>> although it does feel a bit odd setting the callback before creating
>> csound.
>
> I missed Tito's post.  I don't see a need for two different message
> callback functions, though.  Just pass NULL for the CSOUND pointer
> parameter to set the callback as the default, imo.
>
> ~ andy.f
>
> ------------------------------------------------------------------------------
> 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-deve

On Mon, Apr 30, 2012 at 12:35 PM, Michael Gogins
 wrote:
> Using a static variable as a helper is not a good idea for several reasons.
>
> In the first place, the semantics are misleading. The naive user, like me,
> will assume that calling this function before the create function will set a
> static variable that will be shared by all users of Csound. If the callback
> must be set after creation, the implication is clearer that the callback
> must be set for each instance.

If it works both ways, it doesn't matter how naive the user is.  It
will work correctly with either assumption.


> In the second place, with Andy's scheme it actually is possible to corrupt
> the message callbacks in different instances of Csound if different threads
> are doing things concurrently

Use a mutex if thread safety is a concern.  I don't think the
performance hit will be a big deal in this case.

~ andy.f

------------------------------------------------------------------------------
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 Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
 wrote:
> Evidently you did not read my post all the way through. I explicitly said
> that thread safety is not enough protection.
>
> To repeat myself, thread A can completely set the callback, be interrupted,
> then thread B can reset the callback, thread A can be resumed and create an
> instance of Csound with thread B's callback instead of its own callback.

Why would there be a need to set the default message callback from two
different threads?  Granted, somebody may do what you're talking about
not knowing how the internals work, but it could be disallowed on the
csound side fairly easily, couldn't it?

Regardless, if it's too hard to implement, I'd go with Andrés's solution.

Cheers,
~ andy.f

------------------------------------------------------------------------------
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 1, 2012 at 7:27 AM, andy fillebrown
 wrote:
> On Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
>  wrote:
>> Evidently you did not read my post all the way through. I explicitly said
>> that thread safety is not enough protection.
>>
>> To repeat myself, thread A can completely set the callback, be interrupted,
>> then thread B can reset the callback, thread A can be resumed and create an
>> instance of Csound with thread B's callback instead of its own callback.
>
> Why would there be a need to set the default message callback from two
> different threads?  Granted, somebody may do what you're talking about
> not knowing how the internals work, but it could be disallowed on the
> csound side fairly easily, couldn't it?

I see what you're talking about now.  If you wanted to get the
csoundCreate messages in both CsoundVST instances, you couldn't.

End result: I vote for the suggestion from Andrés =)

Cheers,
~ andy.f.

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

Andres made several suggestions in this thread. Which one are you talking about?

Regards,
Mike

On Tue, May 1, 2012 at 8:55 AM, andy fillebrown
 wrote:
> On Tue, May 1, 2012 at 7:27 AM, andy fillebrown
>  wrote:
>> On Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
>>  wrote:
>>> Evidently you did not read my post all the way through. I explicitly said
>>> that thread safety is not enough protection.
>>>
>>> To repeat myself, thread A can completely set the callback, be interrupted,
>>> then thread B can reset the callback, thread A can be resumed and create an
>>> instance of Csound with thread B's callback instead of its own callback.
>>
>> Why would there be a need to set the default message callback from two
>> different threads?  Granted, somebody may do what you're talking about
>> not knowing how the internals work, but it could be disallowed on the
>> csound side fairly easily, couldn't it?
>
> I see what you're talking about now.  If you wanted to get the
> csoundCreate messages in both CsoundVST instances, you couldn't.
>
> End result: I vote for the suggestion from Andrés =)
>
> Cheers,
> ~ andy.f.
>
> ------------------------------------------------------------------------------
> 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

I was referring to Andrés's suggestion of csoundCreate(0,
msg_callback), but after reading your response regarding keeping init
and create separated, I'm not so sure it's a good idea, now.  Perhaps
there is another solution we've not considered, yet?  It just seem
cumbersome to init and create.  Create should just init if it needs
to, imo, but I'm not seeing a way to deal with message callbacks
without the separation (unless thread safety is thrown out =)

Anyway, it's always a learning experience.  Thanks for that.

Cheers,
~ andy.f



On Tue, May 1, 2012 at 9:18 AM, Michael Gogins  wrote:
> Andres made several suggestions in this thread. Which one are you talking about?
>
> Regards,
> Mike
>
> On Tue, May 1, 2012 at 8:55 AM, andy fillebrown
>  wrote:
>> On Tue, May 1, 2012 at 7:27 AM, andy fillebrown
>>  wrote:
>>> On Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
>>>  wrote:
>>>> Evidently you did not read my post all the way through. I explicitly said
>>>> that thread safety is not enough protection.
>>>>
>>>> To repeat myself, thread A can completely set the callback, be interrupted,
>>>> then thread B can reset the callback, thread A can be resumed and create an
>>>> instance of Csound with thread B's callback instead of its own callback.
>>>
>>> Why would there be a need to set the default message callback from two
>>> different threads?  Granted, somebody may do what you're talking about
>>> not knowing how the internals work, but it could be disallowed on the
>>> csound side fairly easily, couldn't it?
>>
>> I see what you're talking about now.  If you wanted to get the
>> csoundCreate messages in both CsoundVST instances, you couldn't.
>>
>> End result: I vote for the suggestion from Andrés =)
>>
>> Cheers,
>> ~ andy.f.
>>
>> ------------------------------------------------------------------------------
>> 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

Actually, I think this suggestion is fine. The reason is that we need
a message callback to be defined for diagnosing what happens
immediately after the createCsound call is made.

If the callback is null, a default callback printing to stdout would be used.

After that, we simply need the ability to reset the callback with a
separate function.

Regards,
Mike

On Tue, May 1, 2012 at 10:08 AM, andy fillebrown
 wrote:
> I was referring to Andrés's suggestion of csoundCreate(0,
> msg_callback), but after reading your response regarding keeping init
> and create separated, I'm not so sure it's a good idea, now.  Perhaps
> there is another solution we've not considered, yet?  It just seem
> cumbersome to init and create.  Create should just init if it needs
> to, imo, but I'm not seeing a way to deal with message callbacks
> without the separation (unless thread safety is thrown out =)
>
> Anyway, it's always a learning experience.  Thanks for that.
>
> Cheers,
> ~ andy.f
>
>
>
> On Tue, May 1, 2012 at 9:18 AM, Michael Gogins  wrote:
>> Andres made several suggestions in this thread. Which one are you talking about?
>>
>> Regards,
>> Mike
>>
>> On Tue, May 1, 2012 at 8:55 AM, andy fillebrown
>>  wrote:
>>> On Tue, May 1, 2012 at 7:27 AM, andy fillebrown
>>>  wrote:
>>>> On Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
>>>>  wrote:
>>>>> Evidently you did not read my post all the way through. I explicitly said
>>>>> that thread safety is not enough protection.
>>>>>
>>>>> To repeat myself, thread A can completely set the callback, be interrupted,
>>>>> then thread B can reset the callback, thread A can be resumed and create an
>>>>> instance of Csound with thread B's callback instead of its own callback.
>>>>
>>>> Why would there be a need to set the default message callback from two
>>>> different threads?  Granted, somebody may do what you're talking about
>>>> not knowing how the internals work, but it could be disallowed on the
>>>> csound side fairly easily, couldn't it?
>>>
>>> I see what you're talking about now.  If you wanted to get the
>>> csoundCreate messages in both CsoundVST instances, you couldn't.
>>>
>>> End result: I vote for the suggestion from Andrés =)
>>>
>>> Cheers,
>>> ~ andy.f.
>>>
>>> ------------------------------------------------------------------------------
>>> 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

Wouldn't changing the callback while the engine is running be a
dangerous operation that could lead to a crash? Or would the callback
be protected, or the user warned?

Cheers,
Andrés

On Tue, May 1, 2012 at 4:04 PM, Michael Gogins  wrote:
> Actually, I think this suggestion is fine. The reason is that we need
> a message callback to be defined for diagnosing what happens
> immediately after the createCsound call is made.
>
> If the callback is null, a default callback printing to stdout would be used.
>
> After that, we simply need the ability to reset the callback with a
> separate function.
>
> Regards,
> Mike
>
> On Tue, May 1, 2012 at 10:08 AM, andy fillebrown
>  wrote:
>> I was referring to Andrés's suggestion of csoundCreate(0,
>> msg_callback), but after reading your response regarding keeping init
>> and create separated, I'm not so sure it's a good idea, now.  Perhaps
>> there is another solution we've not considered, yet?  It just seem
>> cumbersome to init and create.  Create should just init if it needs
>> to, imo, but I'm not seeing a way to deal with message callbacks
>> without the separation (unless thread safety is thrown out =)
>>
>> Anyway, it's always a learning experience.  Thanks for that.
>>
>> Cheers,
>> ~ andy.f
>>
>>
>>
>> On Tue, May 1, 2012 at 9:18 AM, Michael Gogins  wrote:
>>> Andres made several suggestions in this thread. Which one are you talking about?
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, May 1, 2012 at 8:55 AM, andy fillebrown
>>>  wrote:
>>>> On Tue, May 1, 2012 at 7:27 AM, andy fillebrown
>>>>  wrote:
>>>>> On Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
>>>>>  wrote:
>>>>>> Evidently you did not read my post all the way through. I explicitly said
>>>>>> that thread safety is not enough protection.
>>>>>>
>>>>>> To repeat myself, thread A can completely set the callback, be interrupted,
>>>>>> then thread B can reset the callback, thread A can be resumed and create an
>>>>>> instance of Csound with thread B's callback instead of its own callback.
>>>>>
>>>>> Why would there be a need to set the default message callback from two
>>>>> different threads?  Granted, somebody may do what you're talking about
>>>>> not knowing how the internals work, but it could be disallowed on the
>>>>> csound side fairly easily, couldn't it?
>>>>
>>>> I see what you're talking about now.  If you wanted to get the
>>>> csoundCreate messages in both CsoundVST instances, you couldn't.
>>>>
>>>> End result: I vote for the suggestion from Andrés =)
>>>>
>>>> Cheers,
>>>> ~ andy.f.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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/csoun

As long as it is done at block boundaries, and the callback is not buggy, I do not think there is a problem changing the callback on the run.
On 1 May 2012, at 16:33, Andres Cabrera wrote:

> Wouldn't changing the callback while the engine is running be a
> dangerous operation that could lead to a crash? Or would the callback
> be protected, or the user warned?
> 
> Cheers,
> Andrés
> 
> On Tue, May 1, 2012 at 4:04 PM, Michael Gogins  wrote:
>> Actually, I think this suggestion is fine. The reason is that we need
>> a message callback to be defined for diagnosing what happens
>> immediately after the createCsound call is made.
>> 
>> If the callback is null, a default callback printing to stdout would be used.
>> 
>> After that, we simply need the ability to reset the callback with a
>> separate function.
>> 
>> Regards,
>> Mike
>> 
>> On Tue, May 1, 2012 at 10:08 AM, andy fillebrown
>>  wrote:
>>> I was referring to Andrés's suggestion of csoundCreate(0,
>>> msg_callback), but after reading your response regarding keeping init
>>> and create separated, I'm not so sure it's a good idea, now.  Perhaps
>>> there is another solution we've not considered, yet?  It just seem
>>> cumbersome to init and create.  Create should just init if it needs
>>> to, imo, but I'm not seeing a way to deal with message callbacks
>>> without the separation (unless thread safety is thrown out =)
>>> 
>>> Anyway, it's always a learning experience.  Thanks for that.
>>> 
>>> Cheers,
>>> ~ andy.f
>>> 
>>> 
>>> 
>>> On Tue, May 1, 2012 at 9:18 AM, Michael Gogins  wrote:
>>>> Andres made several suggestions in this thread. Which one are you talking about?
>>>> 
>>>> Regards,
>>>> Mike
>>>> 
>>>> On Tue, May 1, 2012 at 8:55 AM, andy fillebrown
>>>>  wrote:
>>>>> On Tue, May 1, 2012 at 7:27 AM, andy fillebrown
>>>>>  wrote:
>>>>>> On Mon, Apr 30, 2012 at 1:20 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> Evidently you did not read my post all the way through. I explicitly said
>>>>>>> that thread safety is not enough protection.
>>>>>>> 
>>>>>>> To repeat myself, thread A can completely set the callback, be interrupted,
>>>>>>> then thread B can reset the callback, thread A can be resumed and create an
>>>>>>> instance of Csound with thread B's callback instead of its own callback.
>>>>>> 
>>>>>> Why would there be a need to set the default message callback from two
>>>>>> different threads?  Granted, somebody may do what you're talking about
>>>>>> not knowing how the internals work, but it could be disallowed on the
>>>>>> csound side fairly easily, couldn't it?
>>>>> 
>>>>> I see what you're talking about now.  If you wanted to get the
>>>>> csoundCreate messages in both CsoundVST instances, you couldn't.
>>>>> 
>>>>> End result: I vote for the suggestion from Andrés =)
>>>>> 
>>>>> Cheers,
>>>>> ~ andy.f.
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> 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

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