From: Victor Lazzarini ()
Date: Dec 1, 2004
Subject:
Re: Updates to csound4
_beginthread is a windows C runtime function for spawning threads.
The key thing here is _WINDOWS definition. With this enabled,
in an msvc binary, the fltkRun runs without any problems.
Victor
At 02:23 01/12/2004, you wrote:
>Art,
>
>I think I localized the problem quickly using gdb. On Linux, console
>csound runs fl.csd without a problem, and so does flcsound. On
>Windows XP, I verified your report, and then ran console csound under
>gdb. If one sets a break point at FL_run, and then runs the program,
>the break point is hit. In contrast, if one sets a break point at
>fltkRun, and then runs the program, the break point is never hit.
>
>So what does this mean? The routine that starts the thread that runs
>FLTK is called, but the thread never runs. Anyone know what
>_beginthread does? Is there a way to print an error message when it
>fails?
>
> From csound/widgets.cpp:
>
>extern "C" void FL_run(FLRUN *p)
>{
>#ifdef _WINDOWS
> threadHandle = _beginthread(fltkRun, 0, NULL);
> if (isActivatedKeyb)
> threadHandle = _beginthread(fltkKeybRun, 0, NULL);
>#elif ...
>#endif
>}
>
>John
> [EMAIL REMOVED] (John D. Ramsdell) writes:
>
> > "Art Hunkins" writes:
> >
> > > Thanks, John, for making this Windows ZIP available (console version).
> > >
> > > I installed this version on two systems of mine: one running Windows
> > > ME; the other, Windows XP. I regret to say that I got the same
> > > results as with your other v6 flCsound .exe: everything seems to
> > > work fine except that the FLTK performance window never appears.
> >
> > Well, given that flCsound is no longer implicated, this eliminates
> > several possibilities. So here is what I think is at least part of
> > the problem.
> >
> > In the Csound GBS version of the csound library, the Csound yield
> > callback registration function in the Csound API is enabled. flCsound
> > uses this function to register a callback that drives FLTK widgets and
> > aborts a run when s_stop is true. This is the code that is ultimately
> > run:
> >
> > int Main::yield(void *data)
> > {
> > Fl::check();
> > if (s_stop) {
> > s_stop = false;
> > return 0;
> > }
> > else
> > return 1;
> > }
> >
> > It's the call to Fl::check() whenever Csound yields to flCsound
> > that ensures that the flCsound GUI is lively.
> >
> > So you ask, how is it that the graphing routine in csound/FL_graph.cpp
> > displays itself? It never registers a yield callback.
> >
> > It displays itself due to a rather ugly hack. The code in
> > csound/csound.c stores the yield callback, and also contains the code
> > that calls the graphing routine.
> >
> > int csoundYield(void *csound)
> > {
> > #if defined HAVE_FLTK
> > void myFLcheck();
> > myFLcheck();
> > #endif
> > return csoundYieldCallback_(&cglob);
> > }
> >
> > Whenever HAVE_FLTK is defined, myFLcheck is called before the
> > registered yield callback. Of course, myFLcheck() is defined in
> > csound/FL_graph.cpp:
> >
> > void myFLcheck()
> > {
> > if (form) Fl::check();
> > }
> >
> > And what about the FLTK opcodes? It turns out they are driven by
> > spawning a thread which calls Fl:run(). The FLrun opcode invokes
> > FL_run, with start the thread. A failure here would explain why
> > the FLTK window never appears. I'm not quite sure how to debug this.
> > I know little about this code.
> >
> > $ grep FL_run csound/*.*
> > csound/entry2.c:void StartPanel(void*), EndPanel(void*), FL_run(void*);
> > csound/entry2.c:{
> "FLrun",S(FLRUN), 1, "", "", FL_run, NULL,
> NULL },
> > csound/widgets.cpp:extern "C" void FL_run(FLRUN *p)
> > $
> >
> > John
> > -- [EMAIL REMOVED] > > (or to http://www.cs.bath.ac.uk/cgi-bin/csound ) [EMAIL REMOVED] >-- [EMAIL REMOVED] > (or to http://www.cs.bath.ac.uk/cgi-bin/csound ) [EMAIL REMOVED]
Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth
-- [EMAIL REMOVED] (or to http://www.cs.bath.ac.uk/cgi-bin/csound ) [EMAIL REMOVED]