Why didn't you drive performance in ksmps blocks? Then you would need no mutex, and your loop conceptually would look like this:

csoundCompile(csound);
while(performing) {
    pollForGuiEvents();
    csoundPerformKsmps(csound);
}

The shared data you need would be host data in Csound. "pollForGuiEvents" would be Fl::wait(0) or the equivalent. It can't get more efficient than this.

The critical point here is the GUI also is not running in its own thread; GUI events are dispatched only when pollForGuiEvents (or whatever it is for that specific GUI framework, they all have something like this) is called. There is only one thread in your application, and it takes turns handling GUI-related events (in pollForGuiEvents()) which invoke callbacks that change variables, etc., still in the same thread, and handling Csound-related events (in csoundPerformKsmps()).

This only works if your GUI is only running when Csound is running. If your GUI needs to run when Csound is not running, this scheme will not work in this simple form. But, you can still modify it to work in that case, if the event handler that starts Csound running performs the above code, which will keep handling GUI events. Then when Csound finishes performing, or if the use sets the "performing" variable to false, then the regular GUI event loop will handle events again.

Is this clear? Or is there some reason why this just will not work for you?

Regards,
Mike



-----Original Message-----
>From: Iain Duncan 
>Sent: Apr 7, 2006 10:22 PM
>To: csound-devel@lists.sourceforge.net
>Subject: [Cs-dev] Object design question for API use
>
>I am still teaching myself OO design, so would like an opinion if gurus
>on here have time to weigh in.
>
>In my front end, all csound controls ( transport, csd name, performing
>flag, etc ) are wrapped up in a class that protects all critical csound
>data variables with a mutex so that gui and other control clients can
>ask for information if csound has time to give it to them. However,
>these same attributes are used in the csound performance thread in the
>kpass loop. The texts I am reading generally say that all data should be
>private and controlled through accessor and mutator functions, however,
>it seems to me that the kpass loop should always execute as quickly as
>possible. Would it be a good idea to make the csound thread into a
>friend class of Csound_Interface so that it can access private data
>quickly, and not lock/unlock mutexex more than it needs to? Or would it
>likely be better to make the entire csound thread and csound data
>construct one class that allows other threads to ask for data?
>
>Thanks
>Iain
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Why didn't you drive performance in ksmps blocks? Then you would need no mutex, and your loop conceptually would look like this:
> 
> csoundCompile(csound);
> while(performing) {
>     pollForGuiEvents();
>     csoundPerformKsmps(csound);
> }
> 
> The shared data you need would be host data in Csound. "pollForGuiEvents" would be Fl::wait(0) or the equivalent. It can't get more efficient than this.
> 
> The critical point here is the GUI also is not running in its own thread; GUI events are dispatched only when pollForGuiEvents (or whatever it is for that specific GUI framework, they all have something like this) is called. There is only one thread in your application, and it takes turns handling GUI-related events (in pollForGuiEvents()) which invoke callbacks that change variables, etc., still in the same thread, and handling Csound-related events (in csoundPerformKsmps()).
> 
> This only works if your GUI is only running when Csound is running. If your GUI needs to run when Csound is not running, this scheme will not work in this simple form. But, you can still modify it to work in that case, if the event handler that starts Csound running performs the above code, which will keep handling GUI events. Then when Csound finishes performing, or if the use sets the "performing" variable to false, then the regular GUI event loop will handle events again.
> 
> Is this clear? Or is there some reason why this just will not work for you?

Thanks Michael. Yes, the above is clear, and I did get the above design
working with your help a while back. The questions now are for a rather
ambitious design in which I intend to have multiple client guis and i/o
modules interacting with a server controller that may in turn spawn
multiple csound threads, with csound threads running at a high priority
and input buffered so that client input modules can not block csound
even under heavy load. Ultimately I will consider it working when a
client gui can drop a *large* sound file into csound from disk without
interrupting playback. This requires buffering input to csound through
queues, etc. I have the basics working, but as I am still learning this
kind of stuff, I keep changing the underlying architecture. I intend to
make this a public project once I have a decent base architecture that
is somewhat stable and passes my tests.

Iain


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net