Complain, politely but incessantly, to the developers.

Another alternative is to take the PortAudio sources into Csound and develop 
them in that context ourselves.

----- Original Message ----- 
From: "Victor Lazzarini" 
To: "Csound Developers Discussion List" 
Sent: Sunday, January 02, 2005 11:14 AM
Subject: [CSOUND-DEV:5614] Cs5 OSX hangups on exit


>
> I have investigated the reasons for csound5 not
> exiting cleanly on OS X. The problems seems to
> be with portaudio not being able to close
> the device, and Pa_AbortStream() not returning
> ever. I tried Pa_CloseStream() and Pa_StopStream()
> with the same results.
>
> If I comment it out, csound exits although with an
> ugly error message from the HAL, but at least it
> does not hang.
>
> So it seems that this is a bug in portaudio. That's
> the problem of using someone else's code. Either
> we go and try to debug it, which I'm not particularly
> inclined to do, or we report it to the developers and
> hope for the best. Any other suggestions?
>
> Victor
>
> 

I offer to take on the task of making the FLTK widgets built into
Csound 4's libcsound thread safe, however, I will gladly defer to
anyone else with an interest in resolving this issue, and am quite
willing to simply take on a supporting role.

I see two issues that must be resolved by the community before the
owner of this task can make progress.  

* The Csound API must change so that the library knows if it must
  create and run a main FLTK GUI thread, or if it must rely on an
  existing thread to do this job.

* The current version of csound/widgets.cpp encodes two ways to act as
  a main thread, see fltkKeybRun and fltkRun.  The keyboard runner has
  some special code to handle keyboard sensing.  Handling both cases
  is difficult.

At this point, I have no idea how to deal with the second issue, which
is why someone else may want to take on this task.

John

[This was originally sent on 1/12/05]

John, 

On 1/2/05 2:00 PM, John D. Ramsdell  etched in stone:

> I offer to take on the task of making the FLTK widgets built into
> Csound 4's libcsound thread safe, however, I will gladly defer to
> anyone else with an interest in resolving this issue, and am quite
> willing to simply take on a supporting role.
> 

Sorry to not have responded to this sooner.  Given what you have found out
about FLTK and given the symptoms of it not working on OS X which make it
seem like a threading problem, I think that this is a fantastic idea.  Since
you have such a good handle on the problem, I definitely think that you
should be the one to make the changes :)

Regarding the code freeze, Cs4 is still in "maintenance mode" and we are
supposed to be fixing bugs :)  And I think these issues constitute a rather
significant bug.

> * The Csound API must change so that the library knows if it must
> create and run a main FLTK GUI thread, or if it must rely on an
> existing thread to do this job.

Another possible option I see now is to make this a compile-time flag and
have two versions of the library.

However, given that the only hosts that use the API (AFAIK) are CsoundVST,
flCsound, and MacCsound (which does not use FLTK), I think that we could
change the API without breaking anything for anyone.

> * The current version of csound/widgets.cpp encodes two ways to act as
> a main thread, see fltkKeybRun and fltkRun.  The keyboard runner has
> some special code to handle keyboard sensing.  Handling both cases
> is difficult.

Disabling the keyboard-reading opcode in the thread-safe library as you
suggested elsewhere sounds fine to me.

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/