Hi,

Can I go ahead and remove the message buffer functions from the API?

I think these functions are not useful as the message buffer is passed
using the userdata, so a host can't use any userdata when using the
message buffer. I think only the message callback mechanism should be
supported, or maybe the message buffer functions should be changed to
create the message buffer internally to avoid using the user data
argument. They should also be made realtime and thread safe...

Cheers,
Andrés

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/list

It's great to see you digging deep into the Csound API again Andres!
You probably have a better understanding of current limitations better
than anyone. I look forward to the jump to hyperspace once Csound 6 is
released!

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

Some updates on this. I've decided not to remove the Message buffer
functions, but rather, I've changed them not to use the user data, and
use the csound struct to hold the messages if the message buffer is
used. I think having this message buffer can actually be a good idea
if it is made such that it is non-blocking and can be queried from a
separate thread without a problem. This way, API users can call the
message buffer functions asynchronously, instead of having the message
callbacks inside the audio thread, which is the current method.

I'll still change the API, and I'm thinking I'll just leave three functions:
csoundEnableMessageBuffer(CSOUND *, int stdOut)
int csoundPopMessage(CSOUND *, const char[] msg, int *attr);
csoundDestroyMessageBuffer(CSOUND *)

so I would remove:
PUBLIC const char*  csoundGetFirstMessage(CSOUND *csound);
int PUBLIC csoundGetFirstMessageAttr(CSOUND *csound);
int PUBLIC csoundGetMessageCnt(CSOUND *csound);

they would be used:
char msg[128];
int attr, msgLen;

msgLen = csoundPopMessage(csound, msg, &attr);


Any comments or suggestions?

Cheers,
Andrés

On Wed, Nov 14, 2012 at 4:39 PM, Andres Cabrera  wrote:
> Hi,
>
> Can I go ahead and remove the message buffer functions from the API?
>
> I think these functions are not useful as the message buffer is passed
> using the userdata, so a host can't use any userdata when using the
> message buffer. I think only the message callback mechanism should be
> supported, or maybe the message buffer functions should be changed to
> create the message buffer internally to avoid using the user data
> argument. They should also be made realtime and thread safe...
>
> Cheers,
> Andrés

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.