I think this is a question for Matt, but it may be for John.

I made it so that libcsound generated on Mac OSX can be built with
real time audio enabled, and made this configuration the default.  To
do this, I added csound/rtcore.c to the list of source files used to
build on Mac OSX, and added "-framework CoreAudio" to the link
command.  To avoid duplicate main routines, I modified
csound/rtcore.c so that the main routine is omitted when DARWIN is
defined.  Is this the correct way to enable real time audio on OSX?  
I hope the code does not depend on initialization performed in main.

I noticed that the only meaningful difference between the files
csound/rtcore.c and csound/rtcoreaudio.c is that one only acknowledges
Matt, but the other acknowledges both Matt and John.  Why are both
files in the repository?

With the above changes, and the previously mentioned edits to
csound/{aiff.c,linevent.c,soundio.c}, Csound 4 compiles and links on
OS X.  Unfortunately, when I try to build the package in an
environment in which FLTK is available, the compilation fails.  It
fails compiling our old "friend" widgets.cpp.

John

$ make
Making all in csound
make  all-am
source='widgets.cpp' object='widgets.o' libtool=no \
depfile='.deps/widgets.Po' tmpdepfile='.deps/widgets.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I.    -fno-exceptions -fno-rtti -g -O2 -Wall -I/Us\ers/ramsdell/include -c -o widgets.o `test -f 'widgets.cpp' || echo './'`widget\s.cpp
widgets.cpp: In function `void displ(float, float)':
widgets.cpp:1786: error: `gcvt' undeclared (first use this function)
widgets.cpp:1786: error: (Each undeclared identifier is reported only once for
   each function it appears in.)
/usr/include/gcc/darwin/3.3/c++/bits/stl_construct.h: At top level:
widgets.cpp:1428: warning: `long unsigned int threadHandle' defined but not
   used
widgets.cpp:1706: warning: `void fltkRun(void*)' defined but not used
widgets.cpp:1737: warning: `void fltkKeybRun(void*)' defined but not used
make[2]: *** [widgets.o] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
$ ../../bin/fltk-config --cxxflags
-I/Users/ramsdell/include
$ ../../bin/fltk-config --version
1.1.4
$

ramsdell@mitre.org (John D. Ramsdell) writes:

> widgets.cpp:1786: error: `gcvt' undeclared (first use this function)

Hmm.  This function in declared in stdlib.h on Linux and has a man page.

http://www.opengroup.org/onlinepubs/007908799/xsh/gcvt.html

John

And I have fixed this many times and people keep returning to 
non-sdtandard code

On 8/24/04 6:55 AM, John D. Ramsdell etched in stone:

> With the above changes, and the previously mentioned edits to
> csound/{aiff.c,linevent.c,soundio.c}, Csound 4 compiles and links on
> OS X.  Unfortunately, when I try to build the package in an
> environment in which FLTK is available, the compilation fails.  It
> fails compiling our old "friend" widgets.cpp.

John, 

I am trying to test your latest updates here on my 10.2.8 machine.  I
installed (for the first time) autoconf, automake, and libtool from the Fink
distribution and did a CVS update.  I first followed the instructions in
README for creating configure and then tried an autoconf -i -f, but
configure failed both times as below:

[fiona:~/Developer/csound] anthony% autoconf --version ; automake --version
autoconf (GNU Autoconf) 2.57
automake (GNU automake) 1.7.4

[fiona:~/Developer/csound] anthony% autoreconf -i
configure.ac: installing `./install-sh'
configure.ac: installing `./mkinstalldirs'
configure.ac: installing `./missing'
Makefile.am: installing `./INSTALL'
info_TEXINFOS: variable `pkgdata_DATA' is used but `pkgdata_DATA' is
undefined
Use of uninitialized value in string eq at /sw/bin/automake line 3681,
 line 1.
doc/Makefile.am: `doc/csoundgbs.texi' missing @setfilename
doc/Makefile.am: texinfo file `pkgdata_DATA' has unrecognized extension
doc/Makefile.am: texinfo file `=' has unrecognized extension
doc/Makefile.am: texinfo file `csoundgbs.html' has unrecognized extension
doc/Makefile.am: texinfo file `csoundgbs.html:' has unrecognized extension
Use of uninitialized value in string eq at /sw/bin/automake line 3681,
 line 1.
doc/Makefile.am: texinfo file `@MAKEINFO@' has unrecognized extension
doc/Makefile.am: texinfo file `-I$(srcdir)' has unrecognized extension
doc/Makefile.am: texinfo file `--html' has unrecognized extension
doc/Makefile.am: texinfo file `--no-split' has unrecognized extension
automake: cannot open < doc/$(srcdir)/csoundgbs.texi: No such file or
directory
 at /sw/bin/automake line 3635
autoreconf: automake failed with exit status: 1

[fiona:~/Developer/csound] anthony% ./configure
[...]
Using ircam
configure: creating ./config.status
config.status: creating Makefile
config.status: creating csound.spec
config.status: creating csound/Makefile
config.status: creating csound/csound-config
config.status: creating flcsound/Makefile
config.status: error: cannot find input file: flcsound/Makefile.in

[fiona:~/Developer/csound] anthony% make
make: Nothing to be done for `all'.

[fiona:~/Developer/csound] anthony% autoconf -i -f

[fiona:~/Developer/csound] anthony% ./configure
[...]
Using ircam
configure: creating ./config.status
config.status: creating Makefile
config.status: creating csound.spec
config.status: creating csound/Makefile
config.status: creating csound/csound-config
config.status: creating flcsound/Makefile
config.status: error: cannot find input file: flcsound/Makefile.in


Any idea what is wrong ?

Anthony

>>>>> "John" == John D Ramsdell  writes:

 John> I think this is a question for Matt, but it may be for John.
 John> I made it so that libcsound generated on Mac OSX can be built with
 John> real time audio enabled, and made this configuration the default.  To
 John> do this, I added csound/rtcore.c to the list of source files used to
 John> build on Mac OSX, and added "-framework CoreAudio" to the link
 John> command.  To avoid duplicate main routines, I modified
 John> csound/rtcore.c so that the main routine is omitted when DARWIN is
 John> defined.  Is this the correct way to enable real time audio on OSX?  
 John> I hope the code does not depend on initialization performed in main.

 John> I noticed that the only meaningful difference between the files
 John> csound/rtcore.c and csound/rtcoreaudio.c is that one only acknowledges
 John> Matt, but the other acknowledges both Matt and John.  Why are both
 John> files in the repository?

Mistake

 John> With the above changes, and the previously mentioned edits to
 John> csound/{aiff.c,linevent.c,soundio.c}, Csound 4 compiles and links on
 John> OS X.  Unfortunately, when I try to build the package in an
 John> environment in which FLTK is available, the compilation fails.  It
 John> fails compiling our old "friend" widgets.cpp.

I have removed gcvt from the sources twice.  It is not a standard
function, and its use is totally frivolous.  Perhaps I have to remove
it again (and again)

==John ffitch

jpff@codemist.co.uk writes:

> I have removed gcvt from the sources twice.  It is not a standard
> function, and its use is totally frivolous.  Perhaps I have to
> remove it again (and again)

John, 

I compared the version of widget.cpp in Csound.tar.gz of package
csound version csound4.23f12 and found quite a few differences with
the csound/widget.cpp in the csound module, however, both files
contained references to gcvt.  I also looked at InOut/widgets.cpp in
the csound5 module, and noticed it does not contain references to
gcvt.  I modified the csound/widget.cpp in the csound module so that
it uses sprintf instead of gcvt by copying code from the csound5
version.  I also fixed csound/{aiff.c,linevent.c,soundio.c} so that
non-standard definitions of the read and write system calls are not
used whenever MACOSX is defined.  With these changes, the system
compiles and builds on OSX.  All changes were documented in ChangeLog.

John

Anthony Kozar  writes:

> doc/Makefile.am: texinfo file `pkgdata_DATA' has unrecognized
> extension

This tells me that your version of autoconf is too old.  I'm using
version 2.59, but I notice they just announced 3.3.  By the way, I'm
using version 1.8.3 of automake.  These versions come as part of
Fedora Core 2.

I'll get a distribution out soon, and I'm pretty sure you'll find it
will compile and link on Mac OS X.

John

ramsdell@mitre.org (John D. Ramsdell) writes:

> Anthony Kozar  writes:
> 
> > doc/Makefile.am: texinfo file `pkgdata_DATA' has unrecognized
> > extension
> 
> This tells me that your version of autoconf is too old.  

This statement is wrong.  I logged into my Mac OSX box, and typed
"make distclean; autoreconf -f", forcing all of the GBS files to be
rebuilt.  No errors were reported.  The installed versions of autoconf
and automake where 2.57 and 1.6.3.  Maybe your automake is too old, I
don't know.

John

On 8/27/04 11:03 AM, John D. Ramsdell etched in stone:

> ramsdell@mitre.org (John D. Ramsdell) writes:
> 
>> Anthony Kozar  writes:
>> 
>>> doc/Makefile.am: texinfo file `pkgdata_DATA' has unrecognized
>>> extension
>> 
>> This tells me that your version of autoconf is too old.
> 
> This statement is wrong.  I logged into my Mac OSX box, and typed
> "make distclean; autoreconf -f", forcing all of the GBS files to be
> rebuilt.  No errors were reported.  The installed versions of autoconf
> and automake where 2.57 and 1.6.3.  Maybe your automake is too old, I
> don't know.

*shrug*  I don't know.

The autoconf/make that I have were the latest that Fink offered me.  I
checked their website though, and autoconf 2.59 and automake 1.8.2 are
available if I upgrade my gcc.

Tried the "make distclean; autoreconf -f" with the same results.  I could
try updating my autotools, but I will probably just wait for your
distribution.  If you want me to test it before you post it to Sourceforge
or something, let me know.

Anthony

I release csound-4.23f12gbs.4.tar.gz in the csoundgbs package.  This
source distributions compiles and links on Mac OSX.  It also contains
an improvement by jpff documented in the ChangeLog as "Skip
initialization options".  Thanks John.

I don't have access to a console, so I've never seen or heard the
results of running binaries built with this release.  This version
does use FLTK if it is available.

John

Success!

(Well mostly).

I was able to compile and install everything with the standard ./configure,
make, and make install.  Since I still don't have X11 or FLTK, configure
correctly set up the compilation without them and did turn on RT Audio.

That is the good news.  The bad news is that RT audio does not work (at
least for me).  I get a Bus Error whenever I use -odac or -odevaudio.  Both
of these work fine with the binary I compiled from jpff's distribution of
4.23f12.

Other differences/problems that I noticed:

1.  The jpff binary reports the message "Csound tidy up: Bus Error" at the
end of some runs (especially csound without arguments) but the GBS version
does not (this is good of course, but I'd like to know why).

2.  The problem that I was looking for originally (not being able to read
orchestra files with line endings from another platform) IS present.

3.  The default installation location of /usr/local/bin is not on the
default path for OS X user accounts (at least under 10.2).


I will go ahead and fix #2 by removing the patch I applied from jpff's
4.23f12. 

I would like to get an OS X binary release out soon.  I will be adding the
materials I have here for making an OS X installer package (with default
location of /usr/bin).  That should make it easy for the average OS X user
to install.  So, #3 may or may not be a problem (depending on what we expect
of someone who is recompiling csound for some reason).  It would be nice to
integrate the installer-maker commands into the GBS build process as an
optional step once I have it working.

I will try to investigate the real-time audio problem as well (which I
suspect may be linked to #1), but I would appreciate advice from anyone who
understands how it works on OS X.

Anthony

On 8/28/04 10:09 AM, John D. Ramsdell etched in stone:

> I release csound-4.23f12gbs.4.tar.gz in the csoundgbs package.  This
> source distributions compiles and links on Mac OSX.  It also contains
> an improvement by jpff documented in the ChangeLog as "Skip
> initialization options".  Thanks John.

Anthony Kozar  writes:

> I was able to compile and install everything with the standard ./configure,
> make, and make install.  Since I still don't have X11 or FLTK, configure
> correctly set up the compilation without them and did turn on RT Audio.

This is good news.  I'm surprised that X11 was not found.  When I
compiled on OSX, the configure script found it without me doing
anything.  Of course, maybe the owner installed extra packages over
the basic OSX distribution.

When the configuration script "turns on RT Audio", that just means it
compiles C and C++ files with RTAUDIO defined, and links in rtcore.c.

> That is the good news.  The bad news is that RT audio does not work (at
> least for me).  I get a Bus Error whenever I use -odac or -odevaudio.  Both
> of these work fine with the binary I compiled from jpff's distribution of
> 4.23f12.

This *is* bad news.

> Other differences/problems that I noticed:
> 
> 1.  The jpff binary reports the message "Csound tidy up: Bus Error" at the
> end of some runs (especially csound without arguments) but the GBS version
> does not (this is good of course, but I'd like to know why).

The lack of an error message is probably another sign that the sound
system is not doing anything.

> 2.  The problem that I was looking for originally (not being able to read
> orchestra files with line endings from another platform) IS present.
> 
> 3.  The default installation location of /usr/local/bin is not on the
> default path for OS X user accounts (at least under 10.2).
> 
> 
> I will go ahead and fix #2 by removing the patch I applied from jpff's
> 4.23f12. 

Sounds good.

> I would like to get an OS X binary release out soon.  I will be adding the
> materials I have here for making an OS X installer package (with default
> location of /usr/bin).  That should make it easy for the average OS X user
> to install.  

Good as I know little about OS X installers.

> So, #3 may or may not be a problem (depending on what we expect
> of someone who is recompiling csound for some reason).  It would be nice to
> integrate the installer-maker commands into the GBS build process as an
> optional step once I have it working.

The Windows installer creator is just a special directory containing
an NSIS installer script (flcsound/nsis).  We should be able to do the
same sort of thing for Mac OSX.

> I will try to investigate the real-time audio problem as well (which I
> suspect may be linked to #1), but I would appreciate advice from anyone who
> understands how it works on OS X.

I'll look through the preprocessor definitions to see if there is a
difference between what the GBS version defines and what the jpff
version defines.  I guess we should make sure both distributions are using
the same versions of rtcore.c.  Other than that check, I'm not sure
what else I can do.

John

> Anthony
> 
> On 8/28/04 10:09 AM, John D. Ramsdell etched in stone:
> 
> > I release csound-4.23f12gbs.4.tar.gz in the csoundgbs package.  This
> > source distributions compiles and links on Mac OSX.  It also contains
> > an improvement by jpff documented in the ChangeLog as "Skip
> > initialization options".  Thanks John.

On 8/30/04 8:09 PM, John D. Ramsdell etched in stone:

> Anthony Kozar  writes:
> 
>> I was able to compile and install everything with the standard ./configure,
>> make, and make install.  Since I still don't have X11 or FLTK, configure
>> correctly set up the compilation without them and did turn on RT Audio.
> 
> This is good news.  I'm surprised that X11 was not found.  When I
> compiled on OSX, the configure script found it without me doing
> anything.  Of course, maybe the owner installed extra packages over
> the basic OSX distribution.

Well, AFAIK, 10.2 and earlier did not come with an X11 installation from
Apple.  Apple provided a beta of their X11 port to 10.2 users for a little
while but are no longer distributing that beta and asking others not to
dsistribute it either.

MacOS X 10.3 comes with Apple's X11 software but does not install it by
default.  It is an optional package as is the X11 SDK so that you can
compile X apps.  So I think the machine you are working on must have had
these extra packages installed.

FLTK is also not provided with MacOS X at all.  But there are FLTK and XFree
distributions available for OS X versions back to 10.1, believe.
  
>> I would like to get an OS X binary release out soon.  I will be adding the
>> materials I have here for making an OS X installer package (with default
>> location of /usr/bin).  That should make it easy for the average OS X user
>> to install.  
> 
> Good as I know little about OS X installers.

Sorry that I haven't been able to work on this at all in the last couple of
weeks.  Once I get a non-GUI version packaged up, I will consider doing a
version with X and FLTK support.  The more important issue though is
probably to get real-time audio working.

Anthony