Csound

Victor Lazzarini wrote:

> I am not aware of the need for any such changes.

That is good news.

Hi All,
=20
> More specifically ? It is still not late for implementing any missing
> functionality, assuming that it does need major changes.

One thing I thought about the other day was an old idea that never got
implemented of having a UDODIR where files ending with *.udo are
automatically loaded and available to a project.

steven

Victor Lazzarini wrote:

> Another thing that just occurred to me, while talking a moment ago with
> Simon Schampijer, is the issue of memory de-allocation. He's been
> working with some FLTK/GL opcodes and it seems that the widget
> opcodes allocate memory but never free it. They don't use the AUXALLOC
> mechanism. There has been talk of a de-init time, has that been 
> implemented,
> and how would one use it? It would be good if an opcode could specify a
> function to be called at that time.

There are these functions in CSOUND for registering a callback function
that is expected to do some sort of cleanup:

int (*RegisterDeinitCallback)(CSOUND *, void *, int (*)(CSOUND *, void *));
int (*RegisterResetCallback)(CSOUND *, void *, int (*)(CSOUND *, void *));

The callback function is called with the void * "user data" pointer
in both cases, and should return zero on success. The registration
functions themselves return a non-zero error value if there was a
failure (most likely not enough memory) registering the callback.

The deinit callback is called when the note is deactivated and removed
from the list of active instrument instances (for this reason, it must be
registered from the "init" routine of an opcode, and the void* pointer
must point to an opcode data structure), while the reset callback - as
suggested by the name - is called at end of performance.

It is important to note that for every call of the registration functions,
there will be exactly one call to the callback function; so, if the init
pass of the opcode is called repeatedly due to the use of reinit, igoto,
or "tied" notes, the callback registration (as well as whatever resource
you intend to deallocate with it) will accumulate unless this case is
detected and handled correctly.

A reset callback is typically registered in opcode_init() or
csoundModuleInit(), and is normally used for global cleanup. Unlike
in the case of a deinit callback, there is no restriction on what the
"user data" pointer can be.
If you register both types of callbacks, the reset one will always be
called after any deinits.

Are the above functions suitable for implementing the functionality
you are looking for ?

They look like what he needs. I'll point him to them (if he's not
listening).

Thanks

Victor

At 17:04 29/08/2005, you wrote:
>Victor Lazzarini wrote:
>
>>Another thing that just occurred to me, while talking a moment ago with
>>Simon Schampijer, is the issue of memory de-allocation. He's been
>>working with some FLTK/GL opcodes and it seems that the widget
>>opcodes allocate memory but never free it. They don't use the AUXALLOC
>>mechanism. There has been talk of a de-init time, has that been implemented,
>>and how would one use it? It would be good if an opcode could specify a
>>function to be called at that time.
>
>There are these functions in CSOUND for registering a callback function
>that is expected to do some sort of cleanup:
>
>int (*RegisterDeinitCallback)(CSOUND *, void *, int (*)(CSOUND *, void *));
>int (*RegisterResetCallback)(CSOUND *, void *, int (*)(CSOUND *, void *));
>
>The callback function is called with the void * "user data" pointer
>in both cases, and should return zero on success. The registration
>functions themselves return a non-zero error value if there was a
>failure (most likely not enough memory) registering the callback.
>
>The deinit callback is called when the note is deactivated and removed
>from the list of active instrument instances (for this reason, it must be
>registered from the "init" routine of an opcode, and the void* pointer
>must point to an opcode data structure), while the reset callback - as
>suggested by the name - is called at end of performance.
>
>It is important to note that for every call of the registration functions,
>there will be exactly one call to the callback function; so, if the init
>pass of the opcode is called repeatedly due to the use of reinit, igoto,
>or "tied" notes, the callback registration (as well as whatever resource
>you intend to deallocate with it) will accumulate unless this case is
>detected and handled correctly.
>
>A reset callback is typically registered in opcode_init() or
>csoundModuleInit(), and is normally used for global cleanup. Unlike
>in the case of a deinit callback, there is no restriction on what the
>"user data" pointer can be.
>If you register both types of callbacks, the reset one will always be
>called after any deinits.
>
>Are the above functions suitable for implementing the functionality
>you are looking for ?
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@...
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

Steven Yi wrote:

> One thing I thought about the other day was an old idea that never got
> implemented of having a UDODIR where files ending with *.udo are
> automatically loaded and available to a project.

Do you mean something like INCDIR (although INCDIR can already also be a
list of directories, not just a single directory), but unconditionally
#including all files with .udo extension ? I do not know, though, how
the parser should automatically find the place in the orchestra where
the .udo files need to be included (most likely just before the first
instrument or opcode definition). Perhaps a new preprocessor symbol
can be added that requests #including all .udo's at that place in an
undefined order, but that is not really elegant.

I used to be a programmer, and I don't have any work or gigs to distract 
me, so I could look at CsoundVST.  I've got boost installed now from 
Darwin Ports, but scons can't find it.  I probably need to alter the 
include path.

Anyway,

Victor Lazzarini wrote:
> I am not aware of the need for any such changes.

It's currently failing with

ranlib libcsound.a
ar: creating archive libcsound.a
gcc -framework Carbon -framework CoreAudio -framework CoreMidi -o csound 
frontends/csound/csound_main.o -L. -L. -L/usr/local/lib -L. -L. 
-L/usr/local/lib -lcsound -lsndfile -lfltk -lpthread -lfltk -lstdc++ 
-lpthread -lm
ld: Undefined symbols:
_pthread_mutex_timedlock

and a previous

gcc -g -O2 -DCSOUND_WITH_API -DMACOSX -Wall -DPIPES -DHAVE_FCNTL_H 
-DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H 
-DHAVE_CTYPE_H -DHAVE_TERMIOS_H -DHAVE_STRING_H -DHAVE_DIRENT_H 
-D__BUILDING_LIBCSOUND -DWINDOWS -DUSE_FLTK -DBETA -I. -IH -c -o 
Top/threads.o Top/threads.c
Top/threads.c: In function `csoundWaitThreadLock':
Top/threads.c:194: warning: implicit declaration of function 
`pthread_mutex_timedlock'

may be implicated.  This is Tiger, with GCC 3.3 as the default compiler.


The last few days, I found it compiled but couldn't find ftgen.


              Graham

Graham Breed wrote:

> It's currently failing with
> 
> ...
>
> ld: Undefined symbols:
> _pthread_mutex_timedlock
> 
> and a previous
> 
> ... 
> 
> Top/threads.o Top/threads.c
> Top/threads.c: In function `csoundWaitThreadLock':
> Top/threads.c:194: warning: implicit declaration of function 
> `pthread_mutex_timedlock'
> 
> may be implicated.  This is Tiger, with GCC 3.3 as the default compiler.

This may be fixed by replacing the #ifdef in Top/threads.c, at line 172:

#if defined(LINUX) || defined(__MACH__)

with

#if defined(LINUX)

with this change, the use of pthread_mutex_timedlock() is disabled
(of course, the timeout parameter of csoundWaitThreadLock() will not
work, any non-zero value will result in an infinite wait time).
It is possible that the pthread library on OS X does not have this
function.

Hi Istvan,

On 8/29/05, Istvan Varga <istvan_v@...> wrote:
> Do you mean something like INCDIR (although INCDIR can already also be a
> list of directories, not just a single directory), but unconditionally
> #including all files with .udo extension ? I do not know, though, how
> the parser should automatically find the place in the orchestra where
> the .udo files need to be included (most likely just before the first
> instrument or opcode definition). Perhaps a new preprocessor symbol
> can be added that requests #including all .udo's at that place in an
> undefined order, but that is not really elegant.

What I was implying was not that the parser should have to parse the
orchestra and upon finding an unkown opcode to try to load it, but
rather to automatically load everything in the UDODIR at startup.  The
order of loading is something that I didn't think about, but I think
would be possible to resolve.  I recently built a ClassLoader in Java
that has to do similar operation of resolving included classes. For
loading UDO's, it could work in this way:

1) grab a listing of the directory contents
2) one by one, open the .udo file and parse any UDO's
3) if an #include is found for another udo, go to that one and start
step 2 from there
4) after finishing loading a UDO, mark as loaded so as to skip if
encountered again

We could start simply by loading any UDO regardless of order with the
assumption that UDO's don't depend on each other, then move on to
resolving dependencies.  I don't think a new preprocessor symbol would
be necessary for all of this.

If an orchestra uses a UDO that isn't defined either in an #include or
is within the UDODIR, then they'll get the standard message that the
opcode doesn't exist, which I think would be enough for someone to
figure out what is wrong and to ask where to get a UDO file.  Users
could always package a .udo file with their CSD's if they release it
to be sure, and perhaps UDO's #included in a CSD can override any UDO
already loaded (is that what happens now, or is there an error for
redefining a UDO?)

steven

Steven Yi wrote:

> What I was implying was not that the parser should have to parse the
> orchestra and upon finding an unkown opcode to try to load it, but
> rather to automatically load everything in the UDODIR at startup.  The
> order of loading is something that I didn't think about, but I think
> would be possible to resolve.  I recently built a ClassLoader in Java
> that has to do similar operation of resolving included classes. For
> loading UDO's, it could work in this way:

I did assume you meant loading all files.
The problem is that parsing the orchestra is done in two separate steps:
the first one is preprocessing (creating a single orchestra in memory as
an array of lines, expanding all #includes and macros, removing ; style
comments, converting CR/CR-LF/LF line endings, etc.), and only after that
is complete, the second stage is tokenization, and converting expressions,
if/then/else/endif, and other high level language features so that in the
end the entire orchestra can be represented as a stream of simple opcodes
(rather like assembly instructions) from which otran() builds instrument
templates. The preprocessor code knows nothing about instruments, opcodes,
or any of the high level syntax in general, but at the same time it is the
only place where including files is possible. Now the question is when and
how the .udo files are to be loaded ?

Graham Breed wrote:

> The last few days, I found it compiled but couldn't find ftgen.

Was it Opcodes/ftgen.c that was not found (at compile time), or
the ftgen opcode (at run time) ? In the latter case, are the plugin
libraries loaded correctly ?

On Aug 29, 2005, at 1:20 PM, Istvan Varga wrote:

> Graham Breed wrote:
>
>> It's currently failing with
>> ...
>>
>> ld: Undefined symbols:
>> _pthread_mutex_timedlock
>> and a previous
>> ... Top/threads.o Top/threads.c
>> Top/threads.c: In function `csoundWaitThreadLock':
>> Top/threads.c:194: warning: implicit declaration of function  
>> `pthread_mutex_timedlock'
>> may be implicated.  This is Tiger, with GCC 3.3 as the default  
>> compiler.
>
> This may be fixed by replacing the #ifdef in Top/threads.c, at line  
> 172:
>
> #if defined(LINUX) || defined(__MACH__)
>
> with
>
> #if defined(LINUX)
>
> with this change, the use of pthread_mutex_timedlock() is disabled
> (of course, the timeout parameter of csoundWaitThreadLock() will not
> work, any non-zero value will result in an infinite wait time).
> It is possible that the pthread library on OS X does not have this
> function.
>

I was having the same issue, but that fixed it right up!

Thanks, Istvan for adding the ATS opcodes -- they're sounding nice!

I'll post some examples when I get home from work... and YES it would  
be amazing if we could add the atsa binary from SourceForge to Csound5.  
This would definitely put Csound far beyond most (if not all) other  
softsynth languages in terms of it's wide range of spectral based  
processing / synthesis, IMHO.

Anthony mentioned the link already (thanks for looking up the license  
info, btw!!)  but here it is again since I believe before the focus was  
the "ats-csound"

http://sourceforge.net/project/showfiles.php? 
group_id=94277&package_id=118299

That is the GUI application for Linux / OSX / Windows (atsh). I believe  
for you need GTK for all OS's in order for it to work.

For Windows:
http://wingtk.sourceforge.net/

The commandline analysis tool (atsa) personally I think it would be  
worth adding to Csound.

Here is the relevant license info from the README included with the ATS  
package from SourceForge (linked above)

"ATS Copyright:
The atsa library and atsh ware developed as part of the "Desarrollo de  
Software
para analisis y sintesis de sonido digital (Digital Sound Analysis and
Synthesis Software Development)" research and development project with
the support of: Universidad Nacional de Quilmes, Buenos Aires, Argentina
(http://www.unq.edu.ar), and the Center for Digital Arts and  
Experimental
Media, University of Washington, Seattle, USA
(http://www.washington.edu/dxarts).

Except where otherwise noted, ATSA and ATSH is Copyright 2002-2004  
Oscar Pablo
Di Liscia, Pete Moss and Juan Pampin.

The authors hereby grant permission to use, copy, modify, distribute,
and license this software and its documentation for any purpose.  No
written agreement, license, or royalty fee is required.  Modifications
to this software may be copyrighted by their authors and need not
follow the licensing terms described here.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY
DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF  
MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.  THIS SOFTWARE
IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE
NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS,  
OR MODIFICATIONS."


-David

I would not disable that, as then the portaudio module will be compromsed.
This compiles fine on all my OSX systems here (10.3.9). So that function
might be missing from Tiger, but I am not sure why, perhaps it has been
substituted by another.

Victor

At 18:20 29/08/2005, you wrote:
>Graham Breed wrote:
>
>>It's currently failing with
>>...
>>
>>ld: Undefined symbols:
>>_pthread_mutex_timedlock
>>and a previous
>>...
>>Top/threads.o Top/threads.c
>>Top/threads.c: In function `csoundWaitThreadLock':
>>Top/threads.c:194: warning: implicit declaration of function 
>>`pthread_mutex_timedlock'
>>may be implicated.  This is Tiger, with GCC 3.3 as the default compiler.
>
>This may be fixed by replacing the #ifdef in Top/threads.c, at line 172:
>
>#if defined(LINUX) || defined(__MACH__)
>
>with
>
>#if defined(LINUX)
>
>with this change, the use of pthread_mutex_timedlock() is disabled
>(of course, the timeout parameter of csoundWaitThreadLock() will not
>work, any non-zero value will result in an infinite wait time).
>It is possible that the pthread library on OS X does not have this
>function.
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@...
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

Victor Lazzarini wrote:

> I would not disable that, as then the portaudio module will be compromsed.

Not necessarily, given that the timeout feature used to be unimplemented
in csoundWaitThreadLock() on all platforms other than Win32, and I only added
it recently for POSIX systems using pthread_mutex_timedlock().

> This compiles fine on all my OSX systems here (10.3.9). So that function
> might be missing from Tiger, but I am not sure why, perhaps it has been
> substituted by another.

Well, then it needs to be found out somehow what versions of OS X have
this function, and what versions do not, and #ifdef's should be added
accordingly. I do not really understand why pthread_mutex_timedlock()
could be removed from Tiger, though, as it is a standard (even if
optional) pthread function; it would make more sense if it was not
present in old releases, but available in newer ones. Perhaps some special
#define is needed (like #define _XOPEN_SOURCE 600 on Linux), or the problem
depends on the version of the development tools and not on that of the OS ?

Well,  I was thinking of not using the #include functionality at all,
and to do the UDODIR parsing after loading the dynamic opcode
libraries.  My thought was that whatever code is tokenizing and the
ORC and translating to templates could simply be called on each file
in the UDODIR, with a modification to mark what #includes are
processed so as to not process twice (as mentioned in previous email).
 I don't know if that is easily doable, but that was what I was
thinking at least.

steven



On 8/29/05, Istvan Varga <istvan_v@...> wrote:
> Steven Yi wrote:
>=20
> > What I was implying was not that the parser should have to parse the
> > orchestra and upon finding an unkown opcode to try to load it, but
> > rather to automatically load everything in the UDODIR at startup.  The
> > order of loading is something that I didn't think about, but I think
> > would be possible to resolve.  I recently built a ClassLoader in Java
> > that has to do similar operation of resolving included classes. For
> > loading UDO's, it could work in this way:
>=20
> I did assume you meant loading all files.
> The problem is that parsing the orchestra is done in two separate steps:
> the first one is preprocessing (creating a single orchestra in memory as
> an array of lines, expanding all #includes and macros, removing ; style
> comments, converting CR/CR-LF/LF line endings, etc.), and only after that
> is complete, the second stage is tokenization, and converting expressions=
,
> if/then/else/endif, and other high level language features so that in the
> end the entire orchestra can be represented as a stream of simple opcodes
> (rather like assembly instructions) from which otran() builds instrument
> templates. The preprocessor code knows nothing about instruments, opcodes=
,
> or any of the high level syntax in general, but at the same time it is th=
e
> only place where including files is possible. Now the question is when an=
d
> how the .udo files are to be loaded ?
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Istvan Varga wrote:

> Was it Opcodes/ftgen.c that was not found (at compile time), or
> the ftgen opcode (at run time) ? In the latter case, are the plugin
> libraries loaded correctly ?

It compiles fine, and then this happens:

error:  no legal opcode, line 12:
gi_sine_wave    ftgen   0, 0, 8192, 10, 1


Not finding the plugin libraries sounds plausible, how would I check? 
The bug's still there as of yesterday's CVS.


                    Graham

Istvan Varga wrote:
> Victor Lazzarini wrote:
> 
>> I would not disable that, as then the portaudio module will be 
>> compromsed.

Does that matter, as CoreAudio's recommended for OSX?

> Well, then it needs to be found out somehow what versions of OS X have
> this function, and what versions do not, and #ifdef's should be added
> accordingly. I do not really understand why pthread_mutex_timedlock()
> could be removed from Tiger, though, as it is a standard (even if
> optional) pthread function; it would make more sense if it was not
> present in old releases, but available in newer ones. Perhaps some special
> #define is needed (like #define _XOPEN_SOURCE 600 on Linux), or the problem
> depends on the version of the development tools and not on that of the OS ?

The development tools come with the OS.  Of course, you can upgrade them.

The copyright on pthread.h is by Apple, 2000-2003.  The latest OSF 
copyright is 1997.  So perhaps they forked an old version?  I can't find 
pthread_mutex_timedlock by grepping the include and library files, so it 
looks like it really isn't there.  The only functions with "timed" in 
them are pthread_cond_timedwait and pthread_cond_timedwait_relative_np.


                   Graham

On Aug 30, 2005, at 3:42 PM, Graham Breed wrote:

> Istvan Varga wrote:
>
>> Was it Opcodes/ftgen.c that was not found (at compile time), or
>> the ftgen opcode (at run time) ? In the latter case, are the plugin
>> libraries loaded correctly ?
>
> It compiles fine, and then this happens:
>
> error:  no legal opcode, line 12:
> gi_sine_wave    ftgen   0, 0, 8192, 10, 1
>
>
> Not finding the plugin libraries sounds plausible, how would I check? 
> The bug's still there as of yesterday's CVS.

Hi Graham,

This definitely sounds like an undefined OPCODEDIR or OPCODEDIR64 
environment variable. As of August 29 I can verify it does work as I've 
been using it from a CVS version compiled on August 29.

The way you can check is by doing simply a

./csound -z

to see an opcode list. If it is not loading plugin libraries it will 
have a little less than 700 opcodes, whereas if the opcode plugin 
libraries you will see over 1000.

To set an environment variable in OSX you do

(bash shell - the default shell)

localhost:~yourname$ export OPCODEDIR="/your/volume/csound/opcodes"

(tenex shell - my personal pref because of FreeBSD nostalgia...)

[localhost:~] yourname% setenv OPCODEDIR /your/volume/csound/opcodes

of course, if you compiled your Csound with double precision you need 
to specify OPCODEDIR64 instead of OPCODEDIR although I believe there is 
a failsafe which will say "WARNING: OPCODEDIR64 undefined, loading 64 
bit libraries from OPCODEDIR". We have the wonderful Csound developers 
to thank for protection such as this.

Hope this helps!


-David

Michael Gogins wrote:
> Just put the boost dir with the header files and all its subdirs into /usr/local/include.

scons customCPPPATH='/opt/local/include/boost-1_32/'

does the trick.  Then with GCC 3.3 it fails on

"""
/opt/local/include/boost-1_32/boost/numeric/ublas/vector_expression.hpp:1924: 
error: due
    to a defect in the G++ 3.2 ABI, G++ has assigned the same mangled 
name to
    two different types
"""

which is probably what's expected to go wrong.  Using Apple's GCC 4.0:

"""
In file included from frontends/CsoundVST/Counterpoint.cpp:2:
frontends/CsoundVST/Counterpoint.hpp:66:20: error: malloc.h: No such 
file or directory
In file included from /opt/local/include/boost-1_32/boost/config.hpp:35,
                  from 
/opt/local/include/boost-1_32/boost/numeric/ublas/config.hpp:24,
                  from 
/opt/local/include/boost-1_32/boost/numeric/ublas/matrix.hpp:20,
                  from frontends/CsoundVST/Counterpoint.hpp:67,
                  from frontends/CsoundVST/Counterpoint.cpp:2:
/opt/local/include/boost-1_32/boost/config/compiler/gcc.hpp:92:7: 
warning: #warning "Unknown compiler version - please run the configure 
tests and report the results"
"""

Maybe you have a different GCC4 as it's in a local path.  But we both 
get the "Unknown compiler version" warnings.  Oh yes, malloc.h is in

/usr/include/malloc/malloc.h
/usr/include/objc/malloc.h
/usr/include/sys/malloc.h



                Graham

I would try manually editing boost/ublas/config.h. Also, try googling the ublas list.

Regards,
Mike

-----Original Message-----
From: Graham Breed <gbreed@...>
Sent: Aug 30, 2005 3:42 PM
To: csound-devel@...
Subject: Re: [Cs-dev] Csound 5 status

Michael Gogins wrote:
> Just put the boost dir with the header files and all its subdirs into /usr/local/include.

scons customCPPPATH='/opt/local/include/boost-1_32/'

does the trick.  Then with GCC 3.3 it fails on

"""
/opt/local/include/boost-1_32/boost/numeric/ublas/vector_expression.hpp:1924: 
error: due
    to a defect in the G++ 3.2 ABI, G++ has assigned the same mangled 
name to
    two different types
"""

which is probably what's expected to go wrong.  Using Apple's GCC 4.0:

"""
In file included from frontends/CsoundVST/Counterpoint.cpp:2:
frontends/CsoundVST/Counterpoint.hpp:66:20: error: malloc.h: No such 
file or directory
In file included from /opt/local/include/boost-1_32/boost/config.hpp:35,
                  from 
/opt/local/include/boost-1_32/boost/numeric/ublas/config.hpp:24,
                  from 
/opt/local/include/boost-1_32/boost/numeric/ublas/matrix.hpp:20,
                  from frontends/CsoundVST/Counterpoint.hpp:67,
                  from frontends/CsoundVST/Counterpoint.cpp:2:
/opt/local/include/boost-1_32/boost/config/compiler/gcc.hpp:92:7: 
warning: #warning "Unknown compiler version - please run the configure 
tests and report the results"
"""

Maybe you have a different GCC4 as it's in a local path.  But we both 
get the "Unknown compiler version" warnings.  Oh yes, malloc.h is in

/usr/include/malloc/malloc.h
/usr/include/objc/malloc.h
/usr/include/sys/malloc.h



                Graham



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi Dave,

This is precisely the combination I have.  I'm using Fedora Core 4
with Planet-CCRMA.  If I use ALSA 1.0.9 from CCRMA or atrpms, I end up
having problems altogether, but I think I'm using the ALSA rpm's from
newrpms (have to check when I get home).  As it is now, I can use
Amaraok and XMMS, play files from the commandline using play, and use
the portaudio plugin with Csound.  (Now that I think of it though, I'm
not sure if I've recompiled PortAudio v19 from source since moving
over to FC4, so wonder if that is what is allowing that to continue to
work...?).

I'll experiment tonight to see if I can figure out anything.  What
problems did you have with 1.0.9 and 2.6.12, and what did you end up
doing to resolve it?

steven


On 8/29/05, Dave Phillips <dlphillips@...> wrote:
> Greetings:
>=20
>   I must note that I had a world of problems with ALSA 1.0.9 + kernel
> 2.6.12. Steven, are you using a package-based distro ? Does your sound
> hardware load correctly, and does it work all right with other apps ?
>=20
> Best,
>=20
> dp
>=20
>=20
>=20
> Istvan Varga wrote:
>=20
> > Steven Yi wrote:
> >
> >> I recently updated to Fedora Core 4 and with that upgraded my ALSA
> >> libs to 1.0.9 (was previously using 1.0.6).  It seems that now I am
> >> unable to use -+rtaudio=3Dalsa as Csound will fail with:
> >>
> >>  *** Failed while trying to set soundcard DMA buffer size
> >> Failed to initialise real time audio output
> >>
> >> I have -b64 -B256 set, using --expression-opt and -m0 -d normally.  My
> >> settings all worked before switching to FC4 and the new alsa libs.
> >> The Portaudio plugin seems to work alright, but would rather prefer to
> >> use the ALSA plugin. I've tried various combinations of -b and -B as
> >> well, without much luck.
> >
> >
> > I only have ALSA 1.0.6 at this time, so some system upgrade is needed
> > to have an attempt at fixing this problem, unless there was an obvious
> > incompatible change in the ALSA API that broke the code below:
> >
> >     /* buffer size, */
> >     if (dev->buffer_smps =3D=3D 0) dev->buffer_smps =3D 1024;
> >     if (dev->buffer_smps < 64) dev->buffer_smps =3D 64;
> >     if (snd_pcm_hw_params_set_buffer_size(dev->handle, hw_params,
> >                                           (snd_pcm_uframes_t)
> > dev->buffer_smps)
> >         < 0) {
> >       sprintf(msg, " *** Failed while trying to set soundcard "
> >                    "DMA buffer size\n");
> >       goto err_return_msg;
> >     }
> >
> > By the way, did you try using different device names ? Does the error
> > occur with all devices, and using any sample rate and number of
> > channels ?
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> > & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@...
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Well, not much progress last night.  I read this today:

http://www.reactivated.net/weblog/archives/2005/06/linux-2612/

And seems that DMIX is enabled by default.  Could this possibly cause
problems setting buffer sizes?  (I'm not using an .asoundrc file, btw)

Anyways, will continue to search for info.  What does everyone think
of if instead of failing if the buffer_size is not settable, to just
log an error to the output to notify the user but to continue working?
 (I'm assuming if setting fails it just defaults to a deafult buffer
size).

steven


On 8/29/05, Steven Yi <stevenyi@...> wrote:
> Hi Dave,
>=20
> This is precisely the combination I have.  I'm using Fedora Core 4
> with Planet-CCRMA.  If I use ALSA 1.0.9 from CCRMA or atrpms, I end up
> having problems altogether, but I think I'm using the ALSA rpm's from
> newrpms (have to check when I get home).  As it is now, I can use
> Amaraok and XMMS, play files from the commandline using play, and use
> the portaudio plugin with Csound.  (Now that I think of it though, I'm
> not sure if I've recompiled PortAudio v19 from source since moving
> over to FC4, so wonder if that is what is allowing that to continue to
> work...?).
>=20
> I'll experiment tonight to see if I can figure out anything.  What
> problems did you have with 1.0.9 and 2.6.12, and what did you end up
> doing to resolve it?
>=20
> steven
>=20
>=20
> On 8/29/05, Dave Phillips <dlphillips@...> wrote:
> > Greetings:
> >
> >   I must note that I had a world of problems with ALSA 1.0.9 + kernel
> > 2.6.12. Steven, are you using a package-based distro ? Does your sound
> > hardware load correctly, and does it work all right with other apps ?
> >
> > Best,
> >
> > dp
> >
> >
> >
> > Istvan Varga wrote:
> >
> > > Steven Yi wrote:
> > >
> > >> I recently updated to Fedora Core 4 and with that upgraded my ALSA
> > >> libs to 1.0.9 (was previously using 1.0.6).  It seems that now I am
> > >> unable to use -+rtaudio=3Dalsa as Csound will fail with:
> > >>
> > >>  *** Failed while trying to set soundcard DMA buffer size
> > >> Failed to initialise real time audio output
> > >>
> > >> I have -b64 -B256 set, using --expression-opt and -m0 -d normally.  =
My
> > >> settings all worked before switching to FC4 and the new alsa libs.
> > >> The Portaudio plugin seems to work alright, but would rather prefer =
to
> > >> use the ALSA plugin. I've tried various combinations of -b and -B as
> > >> well, without much luck.
> > >
> > >
> > > I only have ALSA 1.0.6 at this time, so some system upgrade is needed
> > > to have an attempt at fixing this problem, unless there was an obviou=
s
> > > incompatible change in the ALSA API that broke the code below:
> > >
> > >     /* buffer size, */
> > >     if (dev->buffer_smps =3D=3D 0) dev->buffer_smps =3D 1024;
> > >     if (dev->buffer_smps < 64) dev->buffer_smps =3D 64;
> > >     if (snd_pcm_hw_params_set_buffer_size(dev->handle, hw_params,
> > >                                           (snd_pcm_uframes_t)
> > > dev->buffer_smps)
> > >         < 0) {
> > >       sprintf(msg, " *** Failed while trying to set soundcard "
> > >                    "DMA buffer size\n");
> > >       goto err_return_msg;
> > >     }
> > >
> > > By the way, did you try using different device names ? Does the error
> > > occur with all devices, and using any sample rate and number of
> > > channels ?
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > > Practices
> > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> > > & QA
> > > Security * Process Improvement & Measurement * http://www.sqe.com/bsc=
e5sf
> > > _______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@...
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
>

Hi Steven:

  My apologies for not getting back to you sooner.

  I doubt that dmix is at fault here.

  I resolved my problems with ALSA by recompiling and reinstalling it. 
Demudi came with 1.0.9rc2, I upgraded to 1.0.9b and my difficulties were 
resolved. Btw, the major problem was a failure to install the virmidi 
module. The module was there but the loader said it wasn't. I still do 
not know exactly where the problem started, whether in the kernel, in 
ALSA, or in some system aspect of Demudi. Sorry I'm not much more help. :(

Best,

dp



Steven Yi wrote:

>Well, not much progress last night.  I read this today:
>
>http://www.reactivated.net/weblog/archives/2005/06/linux-2612/
>
>And seems that DMIX is enabled by default.  Could this possibly cause
>problems setting buffer sizes?  (I'm not using an .asoundrc file, btw)
>
>Anyways, will continue to search for info.  What does everyone think
>of if instead of failing if the buffer_size is not settable, to just
>log an error to the output to notify the user but to continue working?
> (I'm assuming if setting fails it just defaults to a deafult buffer
>size).
>
>steven
>
>
>On 8/29/05, Steven Yi <stevenyi@...> wrote:
>  
>
>>Hi Dave,
>>
>>This is precisely the combination I have.  I'm using Fedora Core 4
>>with Planet-CCRMA.  If I use ALSA 1.0.9 from CCRMA or atrpms, I end up
>>having problems altogether, but I think I'm using the ALSA rpm's from
>>newrpms (have to check when I get home).  As it is now, I can use
>>Amaraok and XMMS, play files from the commandline using play, and use
>>the portaudio plugin with Csound.  (Now that I think of it though, I'm
>>not sure if I've recompiled PortAudio v19 from source since moving
>>over to FC4, so wonder if that is what is allowing that to continue to
>>work...?).
>>
>>I'll experiment tonight to see if I can figure out anything.  What
>>problems did you have with 1.0.9 and 2.6.12, and what did you end up
>>doing to resolve it?
>>
>>steven
>>
>>
>>On 8/29/05, Dave Phillips <dlphillips@...> wrote:
>>    
>>
>>>Greetings:
>>>
>>>  I must note that I had a world of problems with ALSA 1.0.9 + kernel
>>>2.6.12. Steven, are you using a package-based distro ? Does your sound
>>>hardware load correctly, and does it work all right with other apps ?
>>>
>>>Best,
>>>
>>>dp
>>>
>>>
>>>
>>>Istvan Varga wrote:
>>>
>>>      
>>>
>>>>Steven Yi wrote:
>>>>
>>>>        
>>>>
>>>>>I recently updated to Fedora Core 4 and with that upgraded my ALSA
>>>>>libs to 1.0.9 (was previously using 1.0.6).  It seems that now I am
>>>>>unable to use -+rtaudio=alsa as Csound will fail with:
>>>>>
>>>>> *** Failed while trying to set soundcard DMA buffer size
>>>>>Failed to initialise real time audio output
>>>>>
>>>>>I have -b64 -B256 set, using --expression-opt and -m0 -d normally.  My
>>>>>settings all worked before switching to FC4 and the new alsa libs.
>>>>>The Portaudio plugin seems to work alright, but would rather prefer to
>>>>>use the ALSA plugin. I've tried various combinations of -b and -B as
>>>>>well, without much luck.
>>>>>          
>>>>>
>>>>I only have ALSA 1.0.6 at this time, so some system upgrade is needed
>>>>to have an attempt at fixing this problem, unless there was an obvious
>>>>incompatible change in the ALSA API that broke the code below:
>>>>
>>>>    /* buffer size, */
>>>>    if (dev->buffer_smps == 0) dev->buffer_smps = 1024;
>>>>    if (dev->buffer_smps < 64) dev->buffer_smps = 64;
>>>>    if (snd_pcm_hw_params_set_buffer_size(dev->handle, hw_params,
>>>>                                          (snd_pcm_uframes_t)
>>>>dev->buffer_smps)
>>>>        < 0) {
>>>>      sprintf(msg, " *** Failed while trying to set soundcard "
>>>>                   "DMA buffer size\n");
>>>>      goto err_return_msg;
>>>>    }
>>>>
>>>>By the way, did you try using different device names ? Does the error
>>>>occur with all devices, and using any sample rate and number of
>>>>channels ?
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>Practices
>>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>>>>& QA
>>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>>>_______________________________________________
>>>>Csound-devel mailing list
>>>>Csound-devel@...
>>>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>        
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>Csound-devel mailing list
>>>Csound-devel@...
>>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>      
>>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@...
>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>  
>