I have committed the following changes to Csound 5:

* A new Csound API function, csoundPerformKsmpsAbsolute, which performs
  one audio output buffer (spout buffer) either with or without a score,
  to facilitate use by clients of the API.

* The external MIDI interface callbacks are now working again (they
  got broken in moving from Csound 4.23 to Csound 5). I have renamed
  the "open" and "close" functions to indicate they are only opening
  and closing the external devices. The signatures of these functions
  have not changed. Csound now internally allocates its
  own MIDI buffers and sets flags for sensing MIDI events if external
  MIDI is enabled. This should make it easier for other external sources
  of real-time MIDI events to use the Csound API, since they no longer
  need to know about or monkey with Csound's internals.

* As a result of these changes, and other changes, CsoundVST is now 
  working not only as a standalone "front end" to Csound, but also as 
  a VST plugin again (at least in Cubase, at least sometimes).

* CsoundVST will now load, edit, and perform standard .csd files, 
  that is, those with only the command line options specified.



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Thanks,
Where can I get it?
Josep M Comajuncosas

Csound5 again fails to compile.  I just did a "cvs update" and scons
and it says
Using single-precision floating point for audio samples.
Checking for C header file sndfile.h... no
The sndfile library is required to build Csound 5.
but it is exactly where it always was:
xenakis:~/Sourceforge/csound5> locate sndfile.h
/usr/local/include/sndfile.h
/home/jpff/Audio/libsndfile-1.0.7/src/sndfile.h
/home/jpff/Audio/libsndfile-1.0.7/src/sndfile.h.in
/home/jpff/Audio/libsndfile-1.0.7/Win32/sndfile.h
/home/jpff/Audio/libsndfile-1.0.7/MacOS9/sndfile.h

So I assume that SConstruct needs to be fixed again.
 
==John ffitch

Hi John,

I came across this situation on windows the other day and what was
happening was that the check for libsndfile.h was happening before the
platform dependent setting of flags, i.e. before /usr/local/include was
added to the commonEnvironment and so I had to move some code around to
get that to work.  (Don't know when that all changed...). 

steven


On Sun, 2004-05-02 at 03:36, jpff@codemist.co.uk wrote:
> Csound5 again fails to compile.  I just did a "cvs update" and scons
> and it says
> Using single-precision floating point for audio samples.
> Checking for C header file sndfile.h... no
> The sndfile library is required to build Csound 5.
> but it is exactly where it always was:
> xenakis:~/Sourceforge/csound5> locate sndfile.h
> /usr/local/include/sndfile.h
> /home/jpff/Audio/libsndfile-1.0.7/src/sndfile.h
> /home/jpff/Audio/libsndfile-1.0.7/src/sndfile.h.in
> /home/jpff/Audio/libsndfile-1.0.7/Win32/sndfile.h
> /home/jpff/Audio/libsndfile-1.0.7/MacOS9/sndfile.h
> 
> So I assume that SConstruct needs to be fixed again.
>  
> ==John ffitch
> 
> 

Well I failed to find a way of building the code.  I tried moving the
test for OS forward to before the 
sndfileFound = configure.CheckHeader("sndfile.h", language = "C")
but it made no difference.  If seems like I am going to have to learn
Python just to go make!
  So frustrating
==John ffitch

Hi John,

I did a fresh checkout and met the same problem as you did and this was
frustrating.  It seems that if you change line 117:

commonEnvironment.Append(CCFLAGS = Split('-DCSOUND_WITH_API -g -O2 
-mthreads'))

to:

commonEnvironment.Append(CCFLAGS = Split('-DCSOUND_WITH_API -g -O2'))

that taking out that mthreads will allow compilation.  -mthreads seems
to be for mingw32 only.  My guess is that when SCons went to do the
header check it probably writes a temp.c file with an #include of the
header and then runs gcc on it to see if it compiles correctly and that
since mthreads is only a mingw flag it gave an error. (I just wrote a
test.c file and tried to compile via "gcc -mthreads" and got an error so
I believe my assumption is correct.)

I have checked in changes that should now get you further along. (I just
met up with some linking errors; looks like libraries are included that
I don't need... will have to look again into this tomorrow.)

steven



On Sun, 2004-05-02 at 15:17, jpff@codemist.co.uk wrote:
> Well I failed to find a way of building the code.  I tried moving the
> test for OS forward to before the 
> sndfileFound = configure.CheckHeader("sndfile.h", language = "C")
> but it made no difference.  If seems like I am going to have to learn
> Python just to go make!
>   So frustrating
> ==John ffitch
> 
> 

Thanks; that does allow me to get to the next introduced error!
OOps/mididevice.c no longer compiles.  Still chasing it; deep in old
code.

==John ffitch