| Well, I'm not sure what's actually happening then, because
[it seemed that] after using gcc4opt =G5 instead of
gcc3opt=G5,
fltk 1.1.6 (and a newly built 1.1.5 in that machine) started
to
work. They did not work before.
The no-threads version runs and the GUI works. The only
problem is that at most-times changing the focus from one
window (panel) to another causes the audio to crackle.
I would prefer to use a threading version, esp. since the
new G5s are all dual processor.
To David Akbari: try building it with no threads, I'm sure
it
will work on 10.4. I realised the threading version problem
is an infinite loop somewhere. I'll try to track it down.
Another quirky thing with OSX is that when running csound
through a graphic frontend (such as a Tk-interpreter-based),
widgets work but without any screen update (the controls do
not change appearance, but work 'blindly'). It appears to
have
something to do with Acqua not being aware of the widgets.
The windows can be moved, so it's even more complicated...
I wished OSX just provided a straightforward X display.
Victor
>
> Victor Lazzarini wrote:
>
> > I seemed to be able to get 1.1.6 working. The trouble
> > was that I was compiling as usual with gcc3opt and the
> > lib I build was with the default compiler (4 I expect).
> > Csound was being built with 3 and fltk with 4. I never
> > realised that there was actually a difference between
> > gcc3opt and gcc4opt, but it appears to exist (I didn't
> check SConstruct).
>
> Well, then probably you need to compile Csound with GCC 4
> (use the CC, CXX, and LINK scons options to select the C
> compiler, C++ compiler, and linker). gcc3opt or gcc4opt do
> not select a particular compiler, the only difference is
> the use of an additional optimization flag by gcc4opt that
> I so far found to be useless.
>
> > But it needs to be built with no threads. What is the
> > actual difference? I thought the widgets had to run in a
> > separate thread. Does it mean that they are running in
> the same thread as the csound engine?
>
> Yes, when built with noFLTKThreads=1, the FLTK GUI runs in
> the audio thread (it still uses Fl::lock() and
> Fl::unlock(), though, but those may not actually be needed
> , and could be #ifdef'd out for noFLTKThreads=1). This may
> improve reliability at the expense of performance.
> Quitting by closing the FLTK windows does not work in this
> case, though, so you need to use ^C.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content,
> downloads, discussions, and more.
> http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |