I find that on Fedora, Csound5 without args segfaults after printing
options, and with realtime audio, yes. And I'm aware of it loading
everything to probe for the opcode registration functions. I don't regard
this as serious problem because in an installation, that directory should
contain only plugins; or, it would be easy to filter out all but dll, so,
and whatever it is on the Mac.

I will look into these bugs, and dcblock as well, as soon as I can. Probably
one or more of the oentries got left out of the table somewhere.

Thanks for your feedback. Let's get this baby on the road!

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Sunday, February 22, 2004 1:02 AM
Subject: [CSOUND-DEV:4071] Re: Major commits to Csound 5


> Hi Michael,
>
> I gave this new version a whirl.  It seems to segfault here (Fedora Core
> 1) if I just run the commandline with no options.  It also segfaults
> with realtime audio.
>
> Running autoreconf gave me some complaints about there being a
> configure.ac and configure.in, but didn't seem like a big deal as it
> chose the .ac file.
>
> I tried non-realtime and it complains that the dcblock opcode is not a
> legal opcode, so didn't get further than that.
>
> Also, I noticed when loading up it seems to try to load everything
> within the OPCODEDIR.  Using the default make install, all .a, .la, .so,
> .so.0, and .so.0.0.0 files for Opcode Libs were put into the OPCODEDIR.
> (Not sure if you were aware of this).
>
> Sorry not much more to say, going to sleep soon.  Will try out more in
> the next few days!
>
> Thanks!
> steven
>
>
>
> On Sat, 2004-02-21 at 20:26, Michael Gogins wrote:
> > I have branched the Csound 5 CVS repository. There is a new
> > "non-makefile-am"
> > branch that contains code prior to my changes and builds using John
Fitch's
> > Makefile.in.
> >
> > The main branch now contains a new build system and all associated
changes
> > (there are many). Csound, the plugin opcodes, and the analysis and
utility
> > programs all link, and Csound loads all plugins and runs, on Windows XP
and
> > Fedore Core 1 Linux. This is all somewhat preliminary but Csound 5 is
now
> > capable of making music.
> >
> > You can try building Csound 5 from CVS by updating your local repository
and
> > executing:
> >
> >     autoreconf -i -f
> >     ./configure
> >     make
> >
> > Other notes on dependencies and building can be found in the README
file.
> >
> > Thanks to John Fitch for implementing use of the sndfile library. It
looks
> > like the audio formatting layer in Csound can now be simplified quite a
bit.
> >
> > On Windows with Cygwin, Csound 5 builds as an API _static_ library, all
> > plugin opcodes as DLLs, the csound program linked with the Csound API,
and
> > all utility programs. Csound runs, loads opcodes, and renders
trapped.csd
> > and xanadu.csd both to soundfile using libsndfile, and trappedrt.csd to
> > real-time audio using PortAudio 19. FLTK graphs work. I have not tested
MIDI
> > or utilities.
> >
> > On Fedora Core 1 Linux with ALSA drivers from Planet CCRMA, Csound 5
builds
> > as as an API _shared_ library, all plugin opcodes as DLLs, the csound
> > program linked with the Csound API, and all utility programs. Csound
runs,
> > loads opcodes, and renders trapped.csd and xanadu.csd to soundfile using
> > libsndfile. PortAudio seg faults, I don't know why yet. The window for
FLTK
> > graphs opens, but the graphs themselves do not appear. I have not tested
> > MIDI or utilities.
> >
> > I succeeded in building PortAudio 19 on Fedora by copying config.sub and
> > config.guess from the csound5 directory to the /usr/local/portaudio
> > directory. I was then able to run ./configure --with-host_os=linux build
> > PortAudio and link it with Csound5. The PortAudio test programs work, so
I
> > don't know yet what's wrong with Csound's use of PortAudio on Linux.
> >
> > I have done no tests on other Linuxes or on Darwin.
> >
> > CHANGES
> >
> > New configure.ac, which is a modified version of John Ramsdell's
> > configure.ac. Thanks to John for providing a framework, implementing the
> > required tests, and enabling me to understand the online documentation.
> >
> > All new Makefile.am, which puts all source configuration in one file for
all
> > targets.
> >
> > Renamed some "main.c" files to prevent naming conflicts caused by having
a
> > single Makefile.am.
> >
> > Moved some opcodes from Opcodes back to OOps due to tangled
dependencies.
> >
> > Plugin opcodes are loaded from the directory pointed to by the OPCODEDIR
> > environment variable. The --shared-lib flag is still effective.
> >
> > Enabled PortAudio output in Csound 5 together with libsndfile, and
changed
> > PortAudio support from v18 to v19. PortAudio input remains to be done.
> >
> > I have renamed libanal.a to libustub.a and moved as much code as
possible
> > from analysis and utility program "main" files to ustub.c.
> >
> > TO DO
> >
> > Enable MIDI on Windows (I have no MIDI interface on Linux).
> >
> > Clean up log printing functions.
> >
> > New csound.h that needs no other headers.
> >
> > Integrate flCsound and CsoundVST into the build system.
> >
> > Various minor code cleanups (warning messages, sysdep.h, etc.).
> >
> >
> >
> > ============================================
> > Michael Gogins
> > gogins at pipeline period com
> > Irreducible Productions
> > CsoundVST, an extended version of Csound for programming music and sound
> > Available at http://sourceforge.net/projects/csound/
> > ============================================
> >
> >
>

Sorry to be a bore on this, but if I d/load the revised Csound5 can
you give me a formula for rebuilding?  I have never understood all the
autothis and autothat. I found creating the configure.in hard enough
to create; I can manage "./configure; make" which is what most
systems I import use.

And .... if the sndfile stuff is working OK, and I need conformation,
I can dismantle all the wav/aiff/aifc/ircam stuff which I really want
to do!  Outstanding issues with sndfile include floating point files
and peak scaling.  I have only tested diskin in simple cases, and I
think soundin and in/ins need testing

==John ffitch

Hi John,

The thing is that most of the time, when downloading src tarballs from
projects, they are likely to be using autotools as well, just that when
they do a src release, the use "make dist-src"  (I think that's the
standard target built...) and that makes a tarball that has the source
and all of the auto-stuff predone, so that the end user downloading the
tarball only has to do "./configure; make; make install".  The
developers themselves are still using configure.in's, Makefile.am's,
etc. 

Yes, this autotools stuff *is* a headache, but I really think that once
we can get to a point where that stuff is working for all of us (which
John R got very far along with in the csound4 repository), consistently,
it'll be the best way for anyone on any platform to be able to download
and compile csound for themselves.  I have to say that until the
autotools work was going on, I was never able to easily compile csound
on any platform, and now I am able to pretty consistently on different
linux systems and cygwin/windows systems I've tried.  

I'm sure none of us think work on the build system is as interesting as
the source code, but it does serve to help get others involved.  

steven


On Sun, 2004-02-22 at 02:31, jpff@codemist.co.uk wrote:
> Sorry to be a bore on this, but if I d/load the revised Csound5 can
> you give me a formula for rebuilding?  I have never understood all the
> autothis and autothat. I found creating the configure.in hard enough
> to create; I can manage "./configure; make" which is what most
> systems I import use.
> 

On Sun, 22 Feb 2004, stevenyi wrote:

> I have to say that until the
> autotools work was going on, I was never able to easily compile csound
> on any platform, and now I am able to pretty consistently on different
> linux systems and cygwin/windows systems I've tried.  
> 

I have the opposite experience.  Since the introduction of these tools I 
have not been able to build Csounmd for ANY platform!

I have been developing multi-platform software for rather a long time 
without this hassle.

I have checked this machine (RedHar7.3 +) and it has 
autoconf (GNU Autoconf) 2.57
automake (GNU automake) 1.4-p5

The Debian machine has I think autoconf 2.19 (turned if off before supper)

The Macintosh has
autoconf (GNU Autoconf) 2.58
automake (GNU automake) 1.7.8

The other machines are probably 2.57/1.4 except the Windows machine which 
does not have any of these.

I do not know a sire from whence I could upgrade these system.  RH have 
ceased to be interested in 7.3.  Macintosh do not seem to have a 
mechanism.

So it looks as if I will be back to mailing changes to people.

==John ff