I have built Csound5 for the Mac with PortMIDI.  So far no testing as
I have no MIDI on the Mac, but I would appreciate some others who do
have the equipment to try.  The snapshot in macosx-snapshot is so
built.

The problem I know about but still have no idea how to fix is that the
realtime audio stutters badly.  I have played around a bit, but with
no improvement.  FLTK passes my trivial test.

Another oddity is that Csound fails to exit cleanly.  Not checked that
yet.

==John ffitch

I decided to make it so that flCsound can be compiled in a mode in
which GUI events are handled in one thread, and the Csound engine
renders in another.  Before designing the code changes, I spend a fair
amount of time reading both the FLTK manual and key parts of its
source code.  What I learned about FLTK 1.1.6 makes me wonder about
other uses of FLTK in Csound4.

The FLTK manual makes promises about the library's behavior to those
who follow some rules.  The rules for a single threaded application
are simple.  For example, to ensure the GUI is responsive, one must
make sure Fl::wait or Fl::check in called often enough so that events
are handled in a timely fashion.

The rules for a multi-threaded applications are more complex, although
FLTK is much simpler than wxWidgets.  The first thing one must do is
ensure the FLTK was compiled with multi-threading support enabled
(--enable-threads).  Before any threads are spawned, the main thread
must call Fl::lock to initialize threading support in FLTK.  A spawned
thread must call Fl::lock before it updates widgets and data, and
finish by calling Fl::unlock.  The main thread is the only one allowed
to call Fl::wait or Fl::check.  When Fl::wait is waiting for input or
timeouts, spawned threads are given access to FLTK.  Finally, a
spawned thread can prod the main thread into processing events by
calling Fl::awake.

Given this background, it turns out that it is fairly straightforward
to make it so that flCsound can be compiled in a mode in which GUI
events are handled in one thread, and the Csound engine renders in
another.  The program appears to work well in this mode until one
renders a piece with an orchestra containing some of the FL* opcodes.
These opcodes need access to FLTK, but the code that makes the access
is not surrounded by a Fl::lock/Fl::unlock pair.  Furthermore, FLrun
invokes Fl::wait via Fl::run in a thread other than flCsound's main
thread.  Needless to say, bad things happen.

It turns out that flCsound compiled in single threaded mode, does
handle pieces that contain FL* opcodes, or so it seems.  The FLTK
authors clearly say one should not rely on this outcome.

John