All of this stuff can be done in Python, either in Python opcodes or in 
CsoundVST. Python has several very complete GUI toolkits (including FLTK and 
wxWidgets). The Python widget callbacks can send events to Csound 
instruments. A special instrument can be used to dispatch these events to 
global variables or to other instruments.

I originally opposed carrying the FLTK opcodes over into Csound 5 but I 
agreed because a number of people who actually use Csound for making music 
were using them. I am sure we can find some reasonable way of accommodating 
all the various threading issues with FLTK.

In the meantime, feel free to explore Python as a way of using Csound to its 
fullest power.

----- Original Message ----- 
From: "steven yi" 
To: "Csound Developers Discussion List" 
Sent: Wednesday, January 19, 2005 10:58 PM
Subject: [CSOUND-DEV:5743] Re: FLTK threading changes


> Hi Matt,
>
> Thinking out loud, is this something we can do more simply, perhaps more 
> simply?
> Say, maybe add a generic function, like csoundHostMessage(char * 
> messageName, char ** values).  The host then could do with the messages 
> what it wishes. For FLTK, it could be something like:
>
> csoundHostMessage("FLTK_create_widget", ["window", "name of window", 
> "etc."])
>
> Hosts would have their own implementations of the csoundHostMessage and 
> could then be enabled to respond to those messsages or not.
> Having a generic system where only strings are passed would allow for some 
> degree of future-proofing.  Also, opcodes could be compiled and 
> distributed with different hosts and if the host isn't compiled to use 
> those messages things the user can be alerted.
> An extra opcode, csoundhostmessage, might be nice to have as well, as 
> users can then manipulate messages they know (a bit dangerous, but 
> potentially useful).
>
> Perhaps also there can be host plugins that can add themselves as 
> hostMessage handlers, but that might go into the realm of 
> over-architcture. =)
>
> Any thoughts?
> steven
>
>
> Matt J. Ingalls wrote:
>
>>
>> i still advocate using a generic control system at the 'csoundlib' level. 
>> i think FLTK opcodes could be modified to go through the API and still be 
>> backwards compatilble.  something like:
>>
>> the API would have to include some FLTK creation functions.  Then 'host' 
>> applications [including console versions] could create the widgets [FTLK 
>> or maybe even something else if certain developers might think they are 
>> too ugly or something].  host application would do its own threading.
>>
>> if all this is unclear i would be happy to provide a more detailed 
>> example of what things would look like on the user, csoundlib, and 
>> hostapp sides.
>>
>>
>> and for the record,
>> what i do in maccsound is run the GUI (carbon not cocoa) stuff in the 
>> application thread and all of csoundlib in another [the audio callback 
>> for real-time apps]
>>
>>
>> -m
>>
>>
>>
>>
>> On Wed, 19 Jan 2005, John D. Ramsdell wrote:
>>
>>> Victor Lazzarini  writes:
>>>
>>>> Wouldn't MacCsound also be one case to consider?
>>>
>>>
>>> Yes, any Mac specific issues will be need to be considered.  Let us
>>> figure out the Windows situation, and then we'll get back to you
>>> looking for help with Macs.
>>>
>>> John
>>>
>>>> At 16:34 19/01/2005, you wrote:
>>>>
>>>>> Victor Lazzarini  writes:
>>>>>
>>>>>> I think it's important to decide now about the FLTK threading
>>>>>> issues. John Ramsdell can implement the necessary changes
>>>>>> to make it thread-safe.  Let's do it!
>>>>>
>>>>>
>>>>> Michael and I are corresponding privately on this topic.  We are
>>>>> sorting out the situation with VST plugins, and wrinkle I had not
>>>>> previously considered.  We'll get back to you all when the two of us
>>>>> think we have a design that allows libcsound to handle the three cases
>>>>> of console Csound, GUI Csound, and VST plugin Csound.
>>>>>
>>>>> John
>>>>
>>>>
>>>> Victor Lazzarini
>>>> Music Technology Laboratory
>>>> Music Department
>>>> National University of Ireland, Maynooth
>>>
>>>
>>>
>>
>>
>>
>
> 

[[ I seem to have just found the mail in this thread.  ]]

"Michael Gogins"  writes:

> I originally opposed carrying the FLTK opcodes over into Csound 5
> but I agreed because a number of people who actually use Csound for
> making music were using them. I am sure we can find some reasonable
> way of accommodating all the various threading issues with FLTK.

I think it is very easy to accommodate FLTK if all the code in
libraries and in opcodes follows the following rules.

(1) The code in methods and constructors that access FLTK must be
    surrounded by Fl::lock() and Fl::unlock().

(2) Calls to Fl::run(), Fl::wait(), and Fl::check() are prohibited.

If libcsound in both Csound 5 and Csound 4 followed the above rules,
there would no need for many of the hacks that have accumulated in the
FLTK parts of the library.

In this approach, console Csound would be written as follows:

-------------------------- ccsound.c ------------------------
#include 
#include 
#include "csound.h"

#if defined HAVE_FLTK
static int yield(void *data)
{
  Fl::check();
  return 1;
}
#endif

int main(int argc, char **argv)
{
  void *csound;
  int rc;	
  /* set stdout to non buffering if not outputing to console window */
  if(!isatty(fileno(stdout)))
  {
      setvbuf(stdout, (char *)NULL, _IONBF, 0);
  }    	
  setlinebuf(stdout);

  csound = csoundCreate(0);
#if defined HAVE_FLTK
  csoundSetYieldCallback(csound, yield);
#endif
  rc = csoundPerform(csound, argc, argv);
  csoundCleanup(csound);
  csoundReset(csound);
  csoundDestroy(csound);
  return rc;
}
-------------------------- ccsound.c ------------------------

The downside of this approach is that console Csound will not work
for real-time performances that use FLTK opcodes, but in this case,
why not use a GUI version Csound?  Let the GUI versions handle
thread creation and event consumption.

So here are the answers I would give for the questions I recently
posed. 

* Do you see a need to make its FLTK routines thread safe?

Yes.

* Should a thread safe version of the library be usable to build both
  a console version of Csound, and an FLTK-based GUI version of
  Csound?

Yes, but console Csound should not be expected to be used for
real-time performances with FLTK opcodes.

* Do you see a need to provide a means by which the library knows if
  it is to be used in a console version of Csound or a GUI version?

No.

* If your answer is yes to all of the above, by what means to you
  propose the library become aware of the mode in which it is to be
  used? 

N/A

John


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

While testing a thread-safe version of libcsound in Csound 4, I
discovered a case in which FLTK's documentation differs from its
behavior.  The good news is there is a simple hack that fixes the
problem in Csound 4, but I'm worried this bug may impinge on the
efforts to implement a better design in Csound 5.

On Windows only, it appears that the most recent thread used to create
a window, must be the one that handles events sent to all windows.  In
particular, if the initial thread creates a window and starts handling
events, and as a side-effect of one of the events, spawns a Csound
rendering thread on a score that invokes FLrun, the bug is exposed.
When the thread created by FLrun creates a window, the window will not
be displayed as a result of the event handling in initial thread.  The
hack to fix the problem is to allow the FLrun thread to handle the
events for all windows created by the process.  In contrast, the Linux
implementation of FLTK correctly allows the initial thread to handle
all event processing in a process, even when windows are created in
threads other than the initial one.

I'm spend some time looking at the FLTK site, and if I've found a bug
they do not seem to know about, I'll submit a bug report.

John


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The FLTK documentation for version 2.0 is much clearer about
multithreading.

http://www.fltk.org/doc-2.0/html/group__multithreading.html

John



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net