[Cs-dev] Csound 5 status

Discussion:

Istvan Varga

2005-08-25 12:36:34 UTC

One month after the previous review of what is left to do before
releasing Csound 5, it is time to update the information on
development status. Does anyone have suggestions on major issues
to be solved, or any (even if small) incompatible changes to the
API that should be done ? What is required to have a "release
candidate" version ?

-------------------------------------------------------
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

Victor NK-X-TODEL918ani

2005-08-29 09:22:11 UTC

Permalink

What is the status of the utilities? I have been away for the
past month and a half and have not been able to follow the
development. I'd say it would be important to make sure they
work. Have the changes to the rtpa IO module been tested with
ASIO and CoreAudio to make sure they work? I have only briefly
tested CoreAudio output and it seems to be OK.

Three things I'd like to say:

1. Testing: we need to see what has not been tested (new opcodes
etc.) and perhaps do a check list to test them.
2. Parser: is it going to be added to csound 5?
3. Documentation: mostly concerning the API, there have been so
many new functions added, I'm wondering whether it's all documented
properly. Also, it would be nice to have an 'opcode development API'
reference, so that opcode developers can see what is available in
the CSOUND 'class' for public use. From simple things, such as
what holds the sampling rate, vectorsize, normalisation level, etc,
to what functions to use to do a FFT, table access, etc.. The thing
to consider now is that csound is no longer simply a 'user-level' music
programming language, but also a 'developer-level'
music application library.

Victor

Post by Istvan Varga
One month after the previous review of what is left to do before
releasing Csound 5, it is time to update the information on
development status. Does anyone have suggestions on major issues
to be solved, or any (even if small) incompatible changes to the
API that should be done ? What is required to have a "release
candidate" version ?
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

2005-08-29 11:27:13 UTC

Permalink

Post by Victor NK-X-TODEL918ani
What is the status of the utilities? I have been away for the
past month and a half and have not been able to follow the
development. I'd say it would be important to make sure they
work.

Most utilities have been successfully converted to plugins and
do work, in particular the most important ones for convolve, pvoc,
adsyn, and lpc analysis seem to be functional.
Also, the commonly used utilities like sndinfo, scale, srconv,
and many others are OK, but some of the less frequently used
ones may have problems. However, the fact is that utilities
have always been very buggy and poorly written, and it was a lot
of work to clean up those that now work well.

Post by Victor NK-X-TODEL918ani
Have the changes to the rtpa IO module been tested with
ASIO and CoreAudio to make sure they work? I have only briefly
tested CoreAudio output and it seems to be OK.

I made some tests with ASIO4ALL on Win2K, and full-duplex audio
(as well as input/output only) with -B 512 worked and was stable.
Also, DirectSound is also OK in all three modes of operation
(input, output, full-duplex), although the buffer size obviously
needs to be higher.
PortAudio on Linux in blocking mode - using -+rtaudio=pa_bl - works
well if there is output only, however, full-duplex has dropouts.
Using callbacks with -+rtaudio=pa_cb, OSS devices are OK in full
duplex mode as well, but ALSA devices hang (this is apparently a bug
in PortAudio and not in Csound, but you have the native ALSA plugin
anyway) if both input and output are used at the same time.
I have no Mac, so could not test that, but I can very well expect
some issues, as this platform tends to be the most problematic one
in many cases, and is also not tested or maintained.

Post by Victor NK-X-TODEL918ani
1. Testing: we need to see what has not been tested (new opcodes
etc.) and perhaps do a check list to test them.

Which opcodes do you mean ? Most of the new opcodes work well (at
least I tested those that I wrote), in fact, older ones that were
already broken in Csound 4 are more likely to have problems.

Post by Victor NK-X-TODEL918ani
2. Parser: is it going to be added to csound 5?

I do not see any progress in this area; while that would answer "no",
John ffitch has probably more to say about parser development.

Post by Victor NK-X-TODEL918ani
3. Documentation: mostly concerning the API, there have been so
many new functions added, I'm wondering whether it's all documented
properly. Also, it would be nice to have an 'opcode development API'
reference, so that opcode developers can see what is available in
the CSOUND 'class' for public use.

For host applications, the answer is currently simple: nothing,
given that CSOUND is an "opaque" incomplete structure type. Use the
PUBLIC functions declared in csound.h and whatever is included by
csound.h.
Plugins can access the contents of the CSOUND structure, and public
members are cleanly separated from the private ones. In fact, an
#ifdef even prevents the use of private data.

Post by Victor NK-X-TODEL918ani
From simple things, such as what holds the sampling rate,

CSOUND.esr

Post by Victor NK-X-TODEL918ani
vectorsize,

CSOUND.ksmps

Post by Victor NK-X-TODEL918ani
normalisation level, etc,

CSOUND.e0dbfs

Post by Victor NK-X-TODEL918ani
to what functions to use to do a FFT,

All functions in CSOUND that have "FFT" in the name.
Documented in H/fftlib.h.

Post by Victor NK-X-TODEL918ani
table access, etc.. The thing

In addition to the usual "ftfind" family of functions, CSOUND.GetTable()
allows for a simple way to get the table length and a MYFLT* pointer to
the table data without having to use a FUNC structure. Was discussed a few
times on the list.

Post by Victor NK-X-TODEL918ani
to consider now is that csound is no longer simply a 'user-level' music
programming language, but also a 'developer-level'
music application library.

I have plans to write manuals for the API functions, in a format similar
to man pages or opcode documentation; probably only as simple plain text,
as the XML format documentation as found in the manual CVS module is much
more difficult and very time consuming to write.

It is important to point out, however, that all the above issues are minor
bug fixing and some documentation, but I still have no feedback at all on
API development, other than the suggestion by Michael Gogins to replace
CSOUND with a C++ class. The most important step towards a "release candidate"
and eventually a final release (which only differs in having bug fixes and
better documentation) is freezing the API, allowing only for backward
compatible changes later. For the last half year or so, I am developing the
Csound API without any cooperation from other people, yet having feedback is
definitely useful to make the interface cleaner, better designed, and more
usable in general.

-------------------------------------------------------
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

Victor NK-X-TODEL918ani

2005-08-29 11:55:55 UTC

Permalink

Regarding the documentation, people that have been developing
opcodes will know where to dig for it, which headers to look, so
learning that CSOUND.esr is sampling rate etc.. is not a problem
We need to make this available to newcomers, so a reference manual would be
good,
in two sections: Host API functions and opcode/module development
API.

Regarding the API, I cannot add much at the moment, as I have not
looked much into it, since I worked on the PD class. There was a lot
of new stuff brought into it, which seems to make it more complete.
As for Michael's suggestion to make CSOUND into C++ class, as
much as I like and use C++, I would prefer we stick to C as far
as the engine and API are concerned.

Victor

Post by Istvan Varga

Post by Victor NK-X-TODEL918ani
Have the changes to the rtpa IO module been tested with
ASIO and CoreAudio to make sure they work? I have only briefly
tested CoreAudio output and it seems to be OK.

Post by Victor NK-X-TODEL918ani
1. Testing: we need to see what has not been tested (new opcodes
etc.) and perhaps do a check list to test them.

Which opcodes do you mean ? Most of the new opcodes work well (at
least I tested those that I wrote), in fact, older ones that were
already broken in Csound 4 are more likely to have problems.

Post by Victor NK-X-TODEL918ani
2. Parser: is it going to be added to csound 5?

I do not see any progress in this area; while that would answer "no",
John ffitch has probably more to say about parser development.

Post by Victor NK-X-TODEL918ani
From simple things, such as what holds the sampling rate,

CSOUND.esr

Post by Victor NK-X-TODEL918ani
vectorsize,

CSOUND.ksmps

Post by Victor NK-X-TODEL918ani
normalisation level, etc,

CSOUND.e0dbfs

Post by Victor NK-X-TODEL918ani
to what functions to use to do a FFT,

All functions in CSOUND that have "FFT" in the name.
Documented in H/fftlib.h.

Post by Victor NK-X-TODEL918ani
table access, etc.. The thing

Post by Victor NK-X-TODEL918ani
to consider now is that csound is no longer simply a 'user-level' music
programming language, but also a 'developer-level'
music application library.

I have plans to write manuals for the API functions, in a format similar
to man pages or opcode documentation; probably only as simple plain text,
as the XML format documentation as found in the manual CVS module is much
more difficult and very time consuming to write.
It is important to point out, however, that all the above issues are minor
bug fixing and some documentation, but I still have no feedback at all on
API development, other than the suggestion by Michael Gogins to replace
CSOUND with a C++ class. The most important step towards a "release candidate"
and eventually a final release (which only differs in having bug fixes and
better documentation) is freezing the API, allowing only for backward
compatible changes later. For the last half year or so, I am developing the
Csound API without any cooperation from other people, yet having feedback is
definitely useful to make the interface cleaner, better designed, and more
usable in general.
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

2005-08-29 12:11:59 UTC

Permalink

Post by Victor NK-X-TODEL918ani
Regarding the documentation, people that have been developing
opcodes will know where to dig for it, which headers to look, so
learning that CSOUND.esr is sampling rate etc.. is not a problem
We need to make this available to newcomers, so a reference manual would
be good,
in two sections: Host API functions and opcode/module development
API.

That is exactly what I have thought of. Perhaps I will begin with the
host API which is simple and has much fewer functions, but, of course,
any help in writing the documentation is really welcome. I can provide
technical information on the various functions for anyone who would
like to contribute manuals.

Post by Victor NK-X-TODEL918ani
Regarding the API, I cannot add much at the moment, as I have not
looked much into it, since I worked on the PD class. There was a lot
of new stuff brought into it, which seems to make it more complete.
As for Michael's suggestion to make CSOUND into C++ class, as
much as I like and use C++, I would prefer we stick to C as far
as the engine and API are concerned.

Well, then it appears that most people (at least those who responded)
prefer keeping the C API, as John ffitch also did not seem to like
the idea of converting to C++, and I would rather stay with the C
interface as well.

-------------------------------------------------------
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

Anthony Kozar

2005-08-29 13:50:39 UTC

Permalink

I would like to reiterate my vote for keeping the API in C as well.

As for commenting on the API, I apologize for not having had the time to
look at it since about March. I would really like to provide some input
here as I believe there are still some holes in functionality that I wanted
to see.

The best solution would seem to be for me to stop advocating my ideas and to
just implement them! (Then get feedback when people don't like how i've
done it).

I would also like to volunteer to check Cscore and make recommendations for
any needed changes in that department.

Another item which I believe needs to checked and probably modified is line
number counting and reporting. IIRC, there are problems here when
#include-ing files and when using macros. Seems to me that it will be
necessary to keep track of more information when loading an orch or score --
perhaps using a stack to store the current line number in each file when
dealing with nested includes.

If I can get the current Csound 5 CVS to compile on OS X, I will begin to
look into these issues.

Anthony Kozar
***@sbcglobal.net
http://akozar.spymac.net/

Post by Istvan Varga

-------------------------------------------------------
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

Victor NK-X-TODEL918ani

2005-08-29 15:10:34 UTC

Permalink

Have you had difficulties in that respect? Here, it has been plain sailing.

Victor

Post by Anthony Kozar
If I can get the current Csound 5 CVS to compile on OS X, I will begin to
look into these issues.

Istvan Varga

2005-08-29 15:28:34 UTC

Permalink

Post by Anthony Kozar
As for commenting on the API, I apologize for not having had the time to
look at it since about March. I would really like to provide some input
here as I believe there are still some holes in functionality that I wanted
to see.

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

Post by Anthony Kozar
I would also like to volunteer to check Cscore and make recommendations for
any needed changes in that department.

That may be a good idea given that currently no one else seems to maintain
Cscore, other than making sure that any relevant files that are part of
the Csound library compile.

Post by Anthony Kozar
Another item which I believe needs to checked and probably modified is line
number counting and reporting. IIRC, there are problems here when
#include-ing files and when using macros. Seems to me that it will be
necessary to keep track of more information when loading an orch or score --
perhaps using a stack to store the current line number in each file when
dealing with nested includes.

I think this would need a rewrite of at least parts of the orchestra
preprocessor (code that deals with converting line endings, removing
comments, expanding #includes and macros, and other low level stuff)
to be done correctly.
Of course, similar changes might also be needed to be done to the score
parser as well, but unfortunately the score language has some ugly
interactions between macros and higher level features that make the
reuse - as opposed to duplication - of code between the orchestra and
score parser difficult.
I had plans to have a look at this, although probably only after Csound 5
is already released, that is something like for example between version
5.01 and 5.02.

Post by Anthony Kozar
If I can get the current Csound 5 CVS to compile on OS X, I will begin to
look into these issues.

Then the most important issue for now is fixing the compile errors,
and making any changes needed to compile Csound 5 on OS X, preferably
without introducing problems on other platforms.

-------------------------------------------------------
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

Victor NK-X-TODEL918ani

2005-08-29 15:34:30 UTC

Permalink

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

Post by Istvan Varga
Then the most important issue for now is fixing the compile errors,
and making any changes needed to compile Csound 5 on OS X, preferably
without introducing problems on other platforms.

Istvan Varga

2005-08-29 15:40:18 UTC

Permalink

Post by Victor NK-X-TODEL918ani
I am not aware of the need for any such changes.

That is good news.

-------------------------------------------------------
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

Graham Breed

2005-08-29 16:58:16 UTC

Permalink

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,

Post by Victor NK-X-TODEL918ani
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

-------------------------------------------------------
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

Istvan Varga

2005-08-29 17:20:20 UTC

Permalink

Post by Graham Breed
It's currently failing with
...
_pthread_mutex_timedlock
and a previous
...
Top/threads.o Top/threads.c
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

David Akbari

2005-08-29 20:37:23 UTC

Permalink

Post by Istvan Varga

Post by Graham Breed
It's currently failing with
...
_pthread_mutex_timedlock
and a previous
... Top/threads.o Top/threads.c
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.

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

-------------------------------------------------------
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

Victor NK-X-TODEL918ani

2005-08-30 12:31:17 UTC

Permalink

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

Post by Istvan Varga

#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
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

2005-08-30 12:49:58 UTC

Permalink

Post by Victor NK-X-TODEL918ani
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().

Post by Victor NK-X-TODEL918ani
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 ?

-------------------------------------------------------
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

Graham Breed

2005-08-30 19:42:13 UTC

Permalink

Post by Istvan Varga

Post by Victor NK-X-TODEL918ani
I would not disable that, as then the portaudio module will be compromsed.

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

Post by Istvan Varga
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

-------------------------------------------------------
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

Anthony Kozar

2005-08-31 14:15:48 UTC

Permalink

I received the error about pthread_mutex_timedlock() as well when I tried to
compile on Monday. I am using OS X 10.2.8 with GCC 3.3.

I notice that Graham was also using GCC 3.3 on 10.4. (Doesn't 10.4 have GCC
4 available as well?) Perhaps this is the common thread?

Anthony Kozar
***@sbcglobal.net
http://akozar.spymac.net/

Post by Istvan Varga

Victor NK-X-TODEL918ani

2005-08-31 17:06:34 UTC

Permalink

In fact there is no such function in 10.3.9 as well. However, looking at
the threads.c code, I see that the call is within #ifdef LINUX #endif.
So here it never gave me any problems (was this #ifdef there all
along or is it new? I never had any compilation/linking issues with
threads.c).

Victor

Post by Anthony Kozar
I received the error about pthread_mutex_timedlock() as well when I tried to
compile on Monday. I am using OS X 10.2.8 with GCC 3.3.
I notice that Graham was also using GCC 3.3 on 10.4. (Doesn't 10.4 have GCC
4 available as well?) Perhaps this is the common thread?
Anthony Kozar
http://akozar.spymac.net/

Post by Istvan Varga

Istvan Varga

2005-08-31 17:14:22 UTC

Permalink

Post by Victor NK-X-TODEL918ani
In fact there is no such function in 10.3.9 as well. However, looking at
the threads.c code, I see that the call is within #ifdef LINUX #endif.
So here it never gave me any problems (was this #ifdef there all
along or is it new? I never had any compilation/linking issues with
threads.c).

You probably have older CVS sources. The __MACH__ was added recently
in addition to the already existing #ifdef LINUX, assuming that the
function exists on OS X as well. As it apparently does not, I will now
remove the check for __MACH__, so pthread_mutex_timedlock() will not
be used on the Mac. Obviously, the lack of that function means that
the timeout parameter of csoundWaitThreadLock() will not work on OS X,
although it never did anyway.

-------------------------------------------------------
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

Graham Breed

2005-08-31 19:37:50 UTC

Permalink

No, it's the same with GCC 4.0. I just default to 3.3 because it breaks
less software. The Posix thread libraries shouldn't be affected by the
compiler version anyway.

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

Istvan Varga

2005-08-29 19:50:10 UTC

Permalink

Post by Graham Breed
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 ?

-------------------------------------------------------
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

Graham Breed

2005-08-30 19:42:05 UTC

Permalink

Post by Istvan Varga
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

-------------------------------------------------------
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

David Akbari

2005-08-30 21:30:41 UTC

Permalink

Post by Graham Breed

Post by Istvan Varga
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 ?

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

-------------------------------------------------------
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

Graham Breed

2005-08-31 10:26:15 UTC

Permalink

Post by David Akbari
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.

Yes, that's it. It looks like it used to find ftgen, although it didn't
load a lot of other opcodes.

Post by David Akbari
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.

I get different numbers, but I suppose that isn't interesting. It does
find ftgen when it runs from the directory with the executable, but not
from a different one.

Post by David Akbari
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.

It'd be nice if they gave us a failsafe for no OPCODEDIR as well, if
it's required for the program to work!

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

Steven Yi

2005-08-29 15:54:00 UTC

Permalink

Hi All,

Post by Istvan Varga
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

-------------------------------------------------------
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

Istvan Varga

2005-08-29 16:15:50 UTC

Permalink

Post by Steven Yi
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.

-------------------------------------------------------
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

Steven Yi

2005-08-29 17:46:38 UTC

Permalink

Hi Istvan,

Post by Istvan Varga
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

-------------------------------------------------------
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

Istvan Varga

2005-08-29 19:38:33 UTC

Permalink

Post by Steven Yi
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

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 ?

-------------------------------------------------------
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

Steven Yi

2005-08-30 17:00:34 UTC

Permalink

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

Post by Istvan Varga

I did assume you meant loading all files.
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 ?
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor NK-X-TODEL918ani

2005-08-29 15:32:58 UTC

Permalink

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.

Victor

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

-------------------------------------------------------
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

Istvan Varga

2005-08-29 16:04:10 UTC

Permalink

Post by Victor NK-X-TODEL918ani
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

Victor NK-X-TODEL918ani

2005-08-29 16:12:28 UTC

Permalink

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

Thanks

Victor

Post by Istvan Varga

There are these functions in CSOUND for registering a callback function
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
https://lists.sourceforge.net/lists/listinfo/csound-devel

Michael Gogins

2005-08-29 13:28:02 UTC

Permalink

My suggestion was rather to make the C API a binary alias for a C++ API. This can be done by replacing the current function pointers in the CSOUND struct with a pointer to a table of function pointers (a virtual function table). Then the C and C++ APIs are binary identical.

Regards,
Mike

-----Original Message-----
From: Victor Lazzarini <***@nuim.ie>
Sent: Aug 29, 2005 7:55 AM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

Regarding the documentation, people that have been developing
opcodes will know where to dig for it, which headers to look, so
learning that CSOUND.esr is sampling rate etc.. is not a problem
We need to make this available to newcomers, so a reference manual would be
good,
in two sections: Host API functions and opcode/module development
API.

Regarding the API, I cannot add much at the moment, as I have not
looked much into it, since I worked on the PD class. There was a lot
of new stuff brought into it, which seems to make it more complete.
As for Michael's suggestion to make CSOUND into C++ class, as
much as I like and use C++, I would prefer we stick to C as far
as the engine and API are concerned.

Victor

Post by Istvan Varga

Post by Victor NK-X-TODEL918ani
Have the changes to the rtpa IO module been tested with
ASIO and CoreAudio to make sure they work? I have only briefly
tested CoreAudio output and it seems to be OK.

Post by Victor NK-X-TODEL918ani
1. Testing: we need to see what has not been tested (new opcodes
etc.) and perhaps do a check list to test them.

Which opcodes do you mean ? Most of the new opcodes work well (at
least I tested those that I wrote), in fact, older ones that were
already broken in Csound 4 are more likely to have problems.

Post by Victor NK-X-TODEL918ani
2. Parser: is it going to be added to csound 5?

I do not see any progress in this area; while that would answer "no",
John ffitch has probably more to say about parser development.

Post by Victor NK-X-TODEL918ani
From simple things, such as what holds the sampling rate,

CSOUND.esr

Post by Victor NK-X-TODEL918ani
vectorsize,

CSOUND.ksmps

Post by Victor NK-X-TODEL918ani
normalisation level, etc,

CSOUND.e0dbfs

Post by Victor NK-X-TODEL918ani
to what functions to use to do a FFT,

All functions in CSOUND that have "FFT" in the name.
Documented in H/fftlib.h.

Post by Victor NK-X-TODEL918ani
table access, etc.. The thing

Post by Victor NK-X-TODEL918ani
to consider now is that csound is no longer simply a 'user-level' music
programming language, but also a 'developer-level'
music application library.

I have plans to write manuals for the API functions, in a format similar
to man pages or opcode documentation; probably only as simple plain text,
as the XML format documentation as found in the manual CVS module is much
more difficult and very time consuming to write.
It is important to point out, however, that all the above issues are minor
bug fixing and some documentation, but I still have no feedback at all on
API development, other than the suggestion by Michael Gogins to replace
CSOUND with a C++ class. The most important step towards a "release candidate"
and eventually a final release (which only differs in having bug fixes and
better documentation) is freezing the API, allowing only for backward
compatible changes later. For the last half year or so, I am developing the
Csound API without any cooperation from other people, yet having feedback is
definitely useful to make the interface cleaner, better designed, and more
usable in general.
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/csound-devel

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

-------------------------------------------------------
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-***@lists.sourceforge.net
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

Michael Gogins

2005-08-29 18:27:21 UTC

Permalink

Just put the boost dir with the header files and all its subdirs into /usr/local/include.

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Aug 29, 2005 12:58 PM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

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,

Post by Victor NK-X-TODEL918ani
I am not aware of the need for any such changes.

Graham Breed

2005-08-30 19:42:04 UTC

Permalink

Post by Michael Gogins
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

Michael Gogins

2005-08-30 20:42:47 UTC

Permalink

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

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Aug 30, 2005 3:42 PM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

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

Graham Breed

2005-08-31 15:41:09 UTC

Permalink

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

You mean boost/numeric/ublas/config.hpp? There's an

#if __GNUC__ >= 3 && __GNUC_MINOR__ >= 4
// By ABI definition see GCC bug id 9982
#define BOOST_UBLAS_USEFUL_ARRAY_PLACEMENT_NEW
#endif

but that's no help for GCC 3.3.

I searched for the "Unknown compiler version" and the link said not to
worry about it. Sure enough, the version of boost I have doesn't know
about GCC 4, but I'll stick with it anyway.

I've made some progress with these additions to custom.py:

elif sys.platform == 'darwin':
platform = 'darwin'
customCPPPATH.append('/usr/include/malloc')
customCPPPATH.append('/opt/local/include/boost-1_32/')
customCPPPATH.append('/usr/include/python2.3')

and a couple of alterations to frontends/CsoundVST/AEffect.h so that
"#if CARBON" becomes "#if CARBON || MACOSX". I don't know what's so
special about Carbon here, but I'm guessing it follows from OSX.

Then, frontends/CsoundVST/CsoundVSTMain.cpp fails and as it's full of
platform-specific #defines with no mention of MACOSX this doesn't
surprise me. The error is:

g++-4.0 -DCSOUND_WITH_API -fexceptions -g -O2 -DCSOUND_WITH_API -DMACOSX
-Wall -DPIPES -DHAVE_FCNTL_H -DHAVE_UNISTD_H -DHAVE_STDINT_H
-DHAVE_MALLOC_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_CTYPE_H
-DHAVE_TERMIOS_H -DHAVE_STRING_H -DHAVE_DIRENT_H -framework -framework
-DWINDOWS -DUSE_FLTK -fPIC -DBETA -I. -IH -I/usr/include/malloc
-I/opt/local/include/boost-1_32 -I/usr/include/python2.3
-I/usr/local/include -I/usr/local/include -Ifrontends/CsoundVST -c -o
frontends/CsoundVST/CsoundVSTMain.os frontends/CsoundVST/CsoundVSTMain.cpp
frontends/CsoundVST/CsoundVSTMain.cpp:32: warning: ignoring #pragma
export on
frontends/CsoundVST/CsoundVSTMain.cpp:61: warning: ignoring #pragma
export off
frontends/CsoundVST/CsoundVSTMain.cpp:42: error: '::main' must return 'int'
frontends/CsoundVST/CsoundVSTMain.cpp: In function `int main(long int
(*)(AEffect*, long int, long int, long int, void*, float))':
frontends/CsoundVST/CsoundVSTMain.cpp:57: error: invalid conversion from
'AEffect*' to 'int'

How can main be expected to return a pointer? I don't know, but it must
work for somebody. Change it to an int and it compiles, but that might
be hiding the problem rather than solving it. Note that in Linux this
is main_plugin, not main.

With that changed, it gets to

g++-4.0 -dynamiclib -o _CsoundVST.dylib
frontends/CsoundVST/AudioEffect.os frontends/
CsoundVST/audioeffectx.os frontends/CsoundVST/Composition.os
frontends/CsoundVST/Conv
ersions.os frontends/CsoundVST/Counterpoint.os
frontends/CsoundVST/CounterpointNode.o
s frontends/CsoundVST/CppSound.os frontends/CsoundVST/CsoundFile.os
frontends/CsoundV
ST/Cell.os frontends/CsoundVST/CsoundVST.os
frontends/CsoundVST/csoundvst_api.os fron
tends/CsoundVST/CsoundVstFltk.os frontends/CsoundVST/CsoundVSTMain.os
frontends/Csoun
dVST/CsoundVstUi.os frontends/CsoundVST/Event.os
frontends/CsoundVST/Hocket.os fronte
nds/CsoundVST/ImageToScore.os frontends/CsoundVST/Lindenmayer.os
frontends/CsoundVST/
MCRM.os frontends/CsoundVST/Midifile.os
frontends/CsoundVST/MusicModel.os frontends/C
soundVST/Node.os frontends/CsoundVST/Random.os
frontends/CsoundVST/Rescale.os fronten
ds/CsoundVST/Score.os frontends/CsoundVST/ScoreNode.os
frontends/CsoundVST/Sequence.o
s frontends/CsoundVST/Shell.os frontends/CsoundVST/StrangeAttractor.os
frontends/Csou
ndVST/System.os frontends/CsoundVST/CsoundVST_wrap.os -L. -L.
-L/usr/local/lib -L. -L
. -L/usr/local/lib -lcsound -lsndfile -lfltk_images -lpng -lz -lfltk
-lpthread -lstdc
++ -lpthread -lm
ld: common symbols not allowed with MH_DYLIB output format with the
-multi_module opt
ion
ld: common symbols not allowed with MH_DYLIB output format with the
-multi_module opt
ion
./libcsound.a(aops.o) definition of common _cpsocfrc (size 32768)
./libcsound.a(window.o) definition of common _mkxyFn (size 4)
./libcsound.a(window.o) definition of common _rdxyFn (size 4)
/usr/bin/libtool: internal link edit command failed
scons: *** [_CsoundVST.dylib] Error 1
scons: building terminated because of errors.

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

Graham Breed

2005-08-31 21:21:42 UTC

Permalink

I'm making some progress with GCC 3.3 and CsoundVST. The answer appears
to be at

http://lists.boost.org/boost-users/2005/01/9504.php

although I don't understand it I added

customCXXFLAGS.append('-fabi-version=0')

to custom.py and I can now get as far with 3.3 as I do with 4.0.

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

Michael Gogins

2005-08-31 16:50:04 UTC

Permalink

The "main" error occurs on some other platforms and already has an #ifdef. Try extending hat #ifdef to include DARWIN or MACOSX. I think the Linux #ifdef is the one you can use.

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Aug 31, 2005 11:41 AM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

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

Graham Breed

2005-08-31 20:05:57 UTC

Permalink

Post by Michael Gogins
The "main" error occurs on some other platforms and already has an #ifdef. Try extending hat #ifdef to include DARWIN or MACOSX. I think the Linux #ifdef is the one you can use.

Unfortunately, "DARWIN" doesn't seem to be defined, which is shame as
that leaves no way to specify a free Darwin system. Anyway, it's happy
with "MACOSX". I added some "static" declarations to get round the
other errors I was having. The latest error, then, is:

g++-4.0 -dynamiclib -o _CsoundVST.dylib
frontends/CsoundVST/AudioEffect.os frontends
CsoundVST/audioeffectx.os frontends/CsoundVST/Composition.os
frontends/CsoundVST/Con
ersions.os frontends/CsoundVST/Counterpoint.os
frontends/CsoundVST/CounterpointNode.
s frontends/CsoundVST/CppSound.os frontends/CsoundVST/CsoundFile.os
frontends/Csound
ST/Cell.os frontends/CsoundVST/CsoundVST.os
frontends/CsoundVST/csoundvst_api.os fro
tends/CsoundVST/CsoundVstFltk.os frontends/CsoundVST/CsoundVSTMain.os
frontends/Csou
dVST/CsoundVstUi.os frontends/CsoundVST/Event.os
frontends/CsoundVST/Hocket.os front
nds/CsoundVST/ImageToScore.os frontends/CsoundVST/Lindenmayer.os
frontends/CsoundVST
MCRM.os frontends/CsoundVST/Midifile.os
frontends/CsoundVST/MusicModel.os frontends/
soundVST/Node.os frontends/CsoundVST/Random.os
frontends/CsoundVST/Rescale.os fronte
ds/CsoundVST/Score.os frontends/CsoundVST/ScoreNode.os
frontends/CsoundVST/Sequence.
s frontends/CsoundVST/Shell.os frontends/CsoundVST/StrangeAttractor.os
frontends/Cso
ndVST/System.os frontends/CsoundVST/CsoundVST_wrap.os -L. -L.
-L/usr/local/lib -L. -
. -L/usr/local/lib -lcsound -lsndfile -lfltk_images -lpng -lz -lfltk
-lpthread -lstd
++ -lpthread -lm
ld: Undefined symbols:
_PyRun_SimpleString
_PyErr_Print
_PyImport_ImportModule
_PyLong_AsLong
_PyObject_CallMethod
_PyObject_GetAttrString
_PySys_SetArgv
__ZN6csound6System12createThreadEPFvPvES1_i
__ZN6csound6System13parsePathnameESsRSsS1_S1_S1_
__ZN6csound6System7executeEPKc
_Py_Initialize
__ZN6csound6System14waitThreadLockEPvm
__ZN6csound6System16createThreadLockEv
__ZN6csound6System16notifyThreadLockEPv
__ZN6csound6System17destroyThreadLockEPv
_PyArg_ParseTuple
_PyCFunction_Type
_PyCObject_FromVoidPtr
_PyCObject_Import
_PyDict_SetItemString
_PyErr_Clear
_PyErr_Fetch
_PyErr_Format
_PyErr_Occurred
_PyErr_SetString
_PyExc_AttributeError
_PyExc_IOError
_PyExc_IndexError
_PyExc_MemoryError
_PyExc_NameError
_PyExc_NotImplementedError
_PyExc_OverflowError
_PyExc_RuntimeError
_PyExc_SyntaxError
_PyExc_SystemError
_PyExc_TypeError
_PyExc_ValueError
_PyExc_ZeroDivisionError
_PyFloat_FromDouble
_PyFloat_Type
_PyInt_FromLong
_PyInt_Type
_PyList_GetItem
_PyList_Size
_PyList_Type
_PyLong_AsDouble
_PyLong_AsUnsignedLong
_PyLong_FromUnsignedLong
_PyLong_Type
_PyModule_AddObject
_PyModule_GetDict
_PyOS_snprintf
_PyObject_CallObject
_PyObject_Free
_PyObject_GetAttr
_PyObject_Init
_PyObject_Malloc
_PyObject_SetAttrString
_PyObject_Size
_PyObject_Str
_PySequence_Check
_PySequence_GetItem
_PySequence_Size
_PyString_AsString
_PyString_FromFormat
_PyString_FromString
_PyString_FromStringAndSize
_PyString_Type
_PyTuple_GetItem
_PyTuple_GetSlice
_PyTuple_Size
_PyType_IsSubtype
_PyType_Type
_Py_BuildValue
_Py_InitModule4
__Py_NoneStruct
__Py_NotImplementedStruct
__Py_TrueStruct
__Py_ZeroStruct
__ZN6csound6System12getFilenamesESs
__ZN6csound6System17getDirectoryNamesESs
__ZN6csound6System25getSharedLibraryExtensionEv
__ZN6csound6System4beepEv
__ZN6csound6System5sleepEd
__ZN6csound6System9shellOpenEPKcS2_
_cpsocfrc
_mkxyFn
_rdxyFn
/usr/bin/libtool: internal link edit command failed

So it's not finding the Python libraries, among other things.

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

Michael Gogins

2005-09-01 01:30:40 UTC

Permalink

Two problems here. As you note, you're failing to link with the Python library, and you need to extend another #ifdef from LINUX to MACOSX for the threading stuff in CsoundVST's System class.

Perhaps you can patch up custom.py to point to your Python library. Perhaps someone who's more familiar with OS X development can help with the Python linkage, or google on the Python and Mac developer lists.

I hope if you get this to compile, that you will either book your changes into Csound 5 CVS (if you are a Csound developer; if not, may wish to become one) or email a zip of them to me so I can merge them.

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Aug 31, 2005 4:05 PM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

Graham Breed

2005-09-01 12:18:49 UTC

Permalink

Post by Michael Gogins
Two problems here. As you note, you're failing to link with the Python library, and you need to extend another #ifdef from LINUX to MACOSX for the threading stuff in CsoundVST's System class.
Perhaps you can patch up custom.py to point to your Python library. Perhaps someone who's more familiar with OS X development can help with the Python linkage, or google on the Python and Mac developer lists.

As it happens, I've used Swig with Python on OSX before, and you don't
have to specify the Python libraries at all. What I did is add
"-undefined suppress -flat_namespace" when linking. But without the
quotes, which get added if I do the obvious with custom.py. Instead,
this works:

customSHLINKFLAGS.append('-undefined')
customSHLINKFLAGS.append('suppress')
customSHLINKFLAGS.append('-flat_namespace')

Or at least appears to. That leaves me with

g++ -o CsoundVST frontends/CsoundVST/csoundvst_main.o -L. -L.
-L/usr/local/lib -L. -L. -lstdc++ -lpthread -lm
ld: Undefined symbols:
_CreateCsoundVST

That's a reassuringly simple error, but at this point I have no idea
what do do about it.

Post by Michael Gogins
I hope if you get this to compile, that you will either book your changes into Csound 5 CVS (if you are a Csound developer; if not, may wish to become one) or email a zip of them to me so I can merge them.

I don't have developer access, and it's reassuring to know I can't
accidentally break anything. How about I send the patches here? Also,
I can post the full scons output, if anybody wants to check the warnings.

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

Anthony Kozar

2005-09-01 21:28:18 UTC

Permalink

I do not think that this is a good idea -- at least for a permanent
solution. Using those two link flags usually indicates that you need to
create a .bundle instead of .dylib. This is a consequence of having two
object files, each having symbols that reference each other.

But I am not sure of the solution. I only know that using those flags
overrides some of the important features of dynamic library linking on OS X
and should generally be avoided.

Anthony

Graham Breed

2005-09-02 09:20:37 UTC

Permalink

Post by Anthony Kozar
I do not think that this is a good idea -- at least for a permanent
solution. Using those two link flags usually indicates that you need to
create a .bundle instead of .dylib. This is a consequence of having two
object files, each having symbols that reference each other.
But I am not sure of the solution. I only know that using those flags
overrides some of the important features of dynamic library linking on OS X
and should generally be avoided.

Don't worry, I found a better way in SConstruct. There are some
platform specific options that had just never been set for OSX, so I
copied the Linux ones.

Current status: the standard build now completes! I'll look at the
answers in my mail this morning for setting the Python path and linking
the dynamic Csound lib.

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

Istvan Varga

2005-09-02 11:23:24 UTC

Permalink

Post by Graham Breed
Current status: the standard build now completes! I'll look at the
answers in my mail this morning for setting the Python path and linking
the dynamic Csound lib.

The dynamic Csound library should already be fixed in the CVS
sources.

-------------------------------------------------------
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

Michael Gogins

2005-09-01 01:32:52 UTC

Permalink

Great, and thanks for the information!

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Aug 31, 2005 5:21 PM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

I'm making some progress with GCC 3.3 and CsoundVST. The answer appears
to be at

http://lists.boost.org/boost-users/2005/01/9504.php

although I don't understand it I added

customCXXFLAGS.append('-fabi-version=0')

to custom.py and I can now get as far with 3.3 as I do with 4.0.

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-***@lists.sourceforge.net
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

Michael Gogins

2005-09-01 16:29:57 UTC

Permalink

It should be easy to deal with the undefined _CreateCsoundVST. Presumably,
you have now built _CsoundVST.so or .dylib or whatever. You now need to add
that library to your link line for csoundvst_main (and perhaps other
libraries as well, see the Linux link line for ideas).

Regards,
Mike

----- Original Message -----
From: "Graham Breed" <***@gmail.com>
To: <csound-***@lists.sourceforge.net>
Sent: Thursday, September 01, 2005 8:18 AM
Subject: Re: [Cs-dev] Csound 5 status

Post by Michael Gogins
Two problems here. As you note, you're failing to link with the Python
library, and you need to extend another #ifdef from LINUX to MACOSX for
the threading stuff in CsoundVST's System class.
Perhaps you can patch up custom.py to point to your Python library.
Perhaps someone who's more familiar with OS X development can help with
the Python linkage, or google on the Python and Mac developer lists.

As it happens, I've used Swig with Python on OSX before, and you don't
have to specify the Python libraries at all. What I did is add
"-undefined suppress -flat_namespace" when linking. But without the
quotes, which get added if I do the obvious with custom.py. Instead, this
customSHLINKFLAGS.append('-undefined')
customSHLINKFLAGS.append('suppress')
customSHLINKFLAGS.append('-flat_namespace')
Or at least appears to. That leaves me with
g++ -o CsoundVST
frontends/CsoundVST/csoundvst_main.o -L. -L. -L/usr/local/lib -L. -L. -lstdc++
-lpthread -lm
_CreateCsoundVST
That's a reassuringly simple error, but at this point I have no idea what
do do about it.

Post by Michael Gogins
I hope if you get this to compile, that you will either book your changes
into Csound 5 CVS (if you are a Csound developer; if not, may wish to
become one) or email a zip of them to me so I can merge them.

I don't have developer access, and it's reassuring to know I can't
accidentally break anything. How about I send the patches here? Also, I
can post the full scons output, if anybody wants to check the warnings.
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
https://lists.sourceforge.net/lists/listinfo/csound-devel

Graham Breed

2005-09-01 21:07:58 UTC

Permalink

Post by Michael Gogins
It should be easy to deal with the undefined _CreateCsoundVST. Presumably,
you have now built _CsoundVST.so or .dylib or whatever. You now need to add
that library to your link line for csoundvst_main (and perhaps other
libraries as well, see the Linux link line for ideas).

You mean in SConstruct? Ah, well, that gives the right solutions to
some of the previous problems. I now have a CsoundVST! And it fails to
run like this:

csound5 ./CsoundVST
Starting CsoundVST...
Localisation of messages is disabled, using default language.
time resolution is 1000.000 ns
BEGAN Shell::runScript()...
==============================================================================================================
==============================================================================================================
PyRun_SimpleString returned 0.
ENDED Shell::runScript().
BEGAN Shell::runScript()...
==============================================================================================================
Traceback (most recent call last):
File "<string>", line 1, in ?
ImportError: No module named CsoundVST
==============================================================================================================
PyRun_SimpleString returned -1.
ENDED Shell::runScript().
BEGAN Shell::runScript()...
==============================================================================================================
AttributeError: 'module' object has no attribute 'csound'
==============================================================================================================
PyRun_SimpleString returned -1.
ENDED Shell::runScript().
Csound tidy up: Segmentation fault

But the build still goes on to fail with

gcc -g -O2 -DCSOUND_WITH_API -DMACOSX -Wall -DPIPES -DHAVE_FCNTL_H
-DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_H -DHAVE_SYS_TIME_H
-DHAVE_SYS_TYPES_H -DHAVE_CTYPE_H -DHAVE_TERMIOS_H -DHAVE_STRING_H
-DHAVE_DIRENT_H -DWINDOWS -DUSE_FLTK -fPIC -DBETA -I. -IH
-I/usr/include/malloc -I/opt/local/include/boost-1_32 -c -o
Opcodes/py/pythonopcodes.os Opcodes/py/pythonopcodes.c
Opcodes/py/pythonopcodes.c:20:20: Python.h: No such file or directory
In file included from Opcodes/py/pythonopcodes.c:21:
Opcodes/py/pythonopcodes.h:24:20: Python.h: No such file or directory
In file included from Opcodes/py/pythonopcodes.c:22:
Opcodes/py/pythonhelper.h:24:20: Python.h: No such file or directory

and so on, with screenfuls of errors. I'll look a this in the morning.

As it happens, I can't build the DLL for csound either.

gcc -g -O2 -DCSOUND_WITH_API -DMACOSX -Wall -DPIPES -DHAVE_FCNTL_H
-DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_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 -fPIC -DBETA
-I. -IH -I/usr/include/malloc -I/opt/local/include/boost-1_32 -c -o
InOut/window.os InOut/window.c
gcc -g -O2 -DCSOUND_WITH_API -DMACOSX -Wall -DPIPES -DHAVE_FCNTL_H
-DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_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 -fPIC -DBETA
-I. -IH -I/usr/include/malloc -I/opt/local/include/boost-1_32 -c -o
OOps/aops.os OOps/aops.c
scons: *** Source file: InOut/FL_graph.o is static and is not compatible
with shared target: libcsound.dylib

I just happened to try that.

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

Istvan Varga

2005-09-01 21:39:59 UTC

Permalink

Post by Graham Breed
As it happens, I can't build the DLL for csound either.
gcc -g -O2 -DCSOUND_WITH_API -DMACOSX -Wall -DPIPES -DHAVE_FCNTL_H
-DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_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 -fPIC -DBETA
-I. -IH -I/usr/include/malloc -I/opt/local/include/boost-1_32 -c -o
InOut/window.os InOut/window.c
gcc -g -O2 -DCSOUND_WITH_API -DMACOSX -Wall -DPIPES -DHAVE_FCNTL_H
-DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_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 -fPIC -DBETA
-I. -IH -I/usr/include/malloc -I/opt/local/include/boost-1_32 -c -o
OOps/aops.os OOps/aops.c
scons: *** Source file: InOut/FL_graph.o is static and is not compatible
with shared target: libcsound.dylib
I just happened to try that.

You have found a bug in SConstruct.
At line 621, replace this

if not ((commonEnvironment['useFLTK'] == '1' and fltkFound)):
print 'CONFIGURATION DECISION: Not building with FLTK for graphs and widgets.'
else:
print 'CONFIGURATION DECISION: Building with FLTK for graphs and widgets.'
fltkEnvironment = csoundLibraryEnvironment.Copy()
if (commonEnvironment['noFLTKThreads'] == '1'):
fltkEnvironment.Append(CCFLAGS = ['-DNO_FLTK_THREADS'])
libCsoundSources.append(fltkEnvironment.Object('InOut/FL_graph.cpp'))
libCsoundSources.append(fltkEnvironment.Object('InOut/winFLTK.c'))

with

if not ((commonEnvironment['useFLTK'] == '1' and fltkFound)):
print 'CONFIGURATION DECISION: Not building with FLTK for graphs and widgets.'
else:
print 'CONFIGURATION DECISION: Building with FLTK for graphs and widgets.'
fltkEnvironment = csoundLibraryEnvironment.Copy()
if (commonEnvironment['noFLTKThreads'] == '1'):
fltkEnvironment.Append(CCFLAGS = ['-DNO_FLTK_THREADS'])
if (commonEnvironment['dynamicCsoundLibrary'] == '1'):
libCsoundSources.append(fltkEnvironment.SharedObject('InOut/FL_graph.cpp'))
libCsoundSources.append(fltkEnvironment.SharedObject('InOut/winFLTK.c'))
else:
libCsoundSources.append(fltkEnvironment.Object('InOut/FL_graph.cpp'))
libCsoundSources.append(fltkEnvironment.Object('InOut/winFLTK.c'))

-------------------------------------------------------
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

Michael Gogins

2005-09-01 22:44:42 UTC

Permalink

You need to make sure the directory where _CsoundVST.so or whatever is located, is identified in your PYTHONPATH environment variable. I have a feeling this may do the job.

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Sep 1, 2005 5:07 PM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

Graham Breed

2005-09-02 12:50:41 UTC

Permalink

Post by Michael Gogins
You need to make sure the directory where _CsoundVST.so or whatever is located, is identified in your PYTHONPATH environment variable. I have a feeling this may do the job.

Yes, it's _CsoundVST.so. There I was trying to be clever and changing
it to .dylib! It runs happily with this command:

env OPCODEDIR=`pwd` PYTHONPATH=`pwd` ./CsoundVST

Here's the patch:

Index: SConstruct
===================================================================
RCS file: /cvsroot/csound/csound5/SConstruct,v
retrieving revision 1.282
diff -u -p -r1.282 SConstruct
--- SConstruct 1 Sep 2005 22:04:46 -0000 1.282
+++ SConstruct 2 Sep 2005 12:35:24 -0000
@@ -1042,6 +1042,17 @@ else:
vstEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
vstEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
guiProgramEnvironment.Prepend(LINKFLAGS = ['-mwindows',
'_CsoundVST.so'])
+ elif getPlatform() == 'darwin':
+ vstEnvironment.Append(LIBS = ['python2.3', 'dl', 'm'])
+ vstEnvironment.Append(CPPPATH = ['/usr/include/python2.3'])
+ vstEnvironment.Append(cxxflags = ['-fabi-version=0']) # if gcc3.2-3
+ if commonEnvironment['Word64']=='1':
+ vstEnvironment.Append(LIBPATH =
['/usr/lib64/python2.3/config'])
+ else:
+ vstEnvironment.Append(LIBPATH = ['/usr/lib/python2.3/config'])
+ vstEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
+ vstEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
+ guiProgramEnvironment.Prepend(LINKFLAGS = ['_CsoundVST.so'])
elif getPlatform() == 'cygwin' or getPlatform() == 'mingw':
pythonImportLibrary =
vstEnvironment.Command('/usr/local/lib/libpython23.a',
'$SYSTEMROOT/System32/python23.dll',
@@ -1216,6 +1227,15 @@ Opcodes/stk/src/Thread.cpp
pyEnvironment.Append(LIBPATH =
['/usr/local/lib/python2.3/config'])
pyEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
pyEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
+ elif getPlatform() == 'darwin':
+ pyEnvironment.Append(LIBS = ['python2.3', 'dl', 'm'])
+ pyEnvironment.Append(CPPPATH = ['/usr/include/python2.3'])
+ if commonEnvironment['Word64']=='1':
+ pyEnvironment.Append(LIBPATH = ['/usr/lib64/python2.3/config'])
+ else:
+ pyEnvironment.Append(LIBPATH = ['/usr/lib/python2.3/config'])
+ pyEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
+ pyEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
elif getPlatform() == 'cygwin' or getPlatform() == 'mingw':
pyEnvironment['ENV']['PATH'] = os.environ['PATH']
pyEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
Index: custom.py
===================================================================
RCS file: /cvsroot/csound/csound5/custom.py,v
retrieving revision 1.22
diff -u -p -r1.22 custom.py
--- custom.py 26 Jun 2005 01:23:15 -0000 1.22
+++ custom.py 2 Sep 2005 12:35:24 -0000
@@ -22,6 +22,12 @@ if sys.platform[:5] == 'linux':
elif sys.platform == 'cygwin':
platform = 'cygwin'
customCPPPATH.append('c:/utah/usr/Python23/include')
+elif sys.platform == 'darwin':
+ platform = 'darwin'
+ customCPPPATH.append('/usr/include/malloc')
+ customCPPPATH.append('/opt/local/include/boost-1_32/')
+ customCPPPATH.append('/usr/include/python2.3')
+ customCXXFLAGS.append('-fabi-version=0')
elif sys.platform[:3] == 'win':
# For the basic build you need MinGW, MSys, and libsndfile.
# Add them here:
Index: frontends/CsoundVST/CsoundVSTMain.cpp
===================================================================
RCS file: /cvsroot/csound/csound5/frontends/CsoundVST/CsoundVSTMain.cpp,v
retrieving revision 1.6
diff -u -p -r1.6 CsoundVSTMain.cpp
--- frontends/CsoundVST/CsoundVSTMain.cpp 28 May 2005 13:00:07
-0000 1.6
+++ frontends/CsoundVST/CsoundVSTMain.cpp 2 Sep 2005 12:35:24 -0000
@@ -36,7 +36,7 @@ bool oome = false;
#if defined(__GNUC__) && defined(WIN32)
#define main main_plugin
extern "C" __declspec(dllexport) AEffect *main_plugin
(audioMasterCallback audioMaster)
-#elif defined(LINUX)
+#elif defined(LINUX) || defined(MACOSX)
AEffect *main_plugin (audioMasterCallback audioMaster)
#else
AEffect *main(audioMasterCallback audioMaster)
Index: frontends/CsoundVST/AEffect.h
===================================================================
RCS file: /cvsroot/csound/csound5/frontends/CsoundVST/AEffect.h,v
retrieving revision 1.5
diff -u -p -r1.5 AEffect.h
--- frontends/CsoundVST/AEffect.h 28 May 2005 13:00:07 -0000 1.5
+++ frontends/CsoundVST/AEffect.h 2 Sep 2005 12:35:26 -0000
@@ -20,7 +20,7 @@
long value, void *ptr, float opt));
*/

-#if CARBON
+#if CARBON || MACOSX
#if PRAGMA_STRUCT_ALIGN || __MWERKS__
#pragma options align=mac68k
#endif
@@ -178,7 +178,7 @@ enum

// will always return true.
};

-#if CARBON
+#if CARBON || MACOSX
#if PRAGMA_STRUCT_ALIGN || __MWERKS__
#pragma options align=reset
#endif
Index: frontends/CsoundVST/System.cpp
===================================================================
RCS file: /cvsroot/csound/csound5/frontends/CsoundVST/System.cpp,v
retrieving revision 1.16
diff -u -p -r1.16 System.cpp
--- frontends/CsoundVST/System.cpp 26 Aug 2005 17:47:54 -0000 1.16
+++ frontends/CsoundVST/System.cpp 2 Sep 2005 12:35:29 -0000
@@ -698,7 +698,7 @@ namespace csound
beep();
}

-#elif defined(LINUX)
+#elif defined(LINUX) || defined(MACOSX)

#include <dlfcn.h>
#include <dirent.h>
Index: InOut/window.c
===================================================================
RCS file: /cvsroot/csound/csound5/InOut/window.c,v
retrieving revision 1.14
diff -u -p -r1.14 window.c
--- InOut/window.c 12 Aug 2005 19:01:23 -0000 1.14
+++ InOut/window.c 2 Sep 2005 12:35:31 -0000
@@ -40,11 +40,13 @@ static void (*killFn)(CSOUND *, WINDAT *
extern void KillAscii(CSOUND *, WINDAT *);
extern void KillGraph(CSOUND *, WINDAT *);
/* pointer to xyinput window creator */
- void (*mkxyFn)(CSOUND *, XYINDAT *, MYFLT, MYFLT);
+/* globals must have a value assigned in OSX */
+/* c.f. http://wiki.tcl.tk/2923 */
+ void (*mkxyFn)(CSOUND *, XYINDAT *, MYFLT, MYFLT) = NULL;
static void MkXYDummy(CSOUND *, XYINDAT *, MYFLT, MYFLT);
extern void MakeXYin(CSOUND *, XYINDAT *, MYFLT, MYFLT);
/* pointer to xyinput window reader */
- void (*rdxyFn)(CSOUND *, XYINDAT *);
+ void (*rdxyFn)(CSOUND *, XYINDAT *) = NULL;
static void RdXYDummy(CSOUND *, XYINDAT *);
extern void ReadXYin(CSOUND *, XYINDAT *);

Index: OOps/aops.c
===================================================================
RCS file: /cvsroot/csound/csound5/OOps/aops.c,v
retrieving revision 1.43
diff -u -p -r1.43 aops.c
--- OOps/aops.c 26 Aug 2005 17:47:53 -0000 1.43
+++ OOps/aops.c 2 Sep 2005 12:35:35 -0000
@@ -33,7 +33,8 @@
#define ONEdLOG2 (1.4426950408889634074)

/* static lookup tables, initialised once at start-up */
- MYFLT cpsocfrc[OCTRES];
+/* dummy initialization for OSX, c.f. http://wiki.tcl.tk/2923 */
+ MYFLT cpsocfrc[OCTRES] = {};
static MYFLT powerof2[4096];

/* initialise the tables, called by csoundInitialize() */

-------------------------------------------------------
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

Istvan Varga

2005-09-02 14:32:13 UTC

Permalink

The changes have been applied to the CVS sources.

Post by Michael Gogins
Regards,
Mike
-----Original Message-----
Sent: Sep 2, 2005 8:50 AM
Subject: Re: [Cs-dev] Csound 5 status

Post by Michael Gogins
You need to make sure the directory where _CsoundVST.so or whatever is located, is identified in your PYTHONPATH environment variable. I have a feeling this may do the job.

Yes, it's _CsoundVST.so. There I was trying to be clever and changing
env OPCODEDIR=`pwd` PYTHONPATH=`pwd` ./CsoundVST
Index: SConstruct
===================================================================
RCS file: /cvsroot/csound/csound5/SConstruct,v
retrieving revision 1.282
diff -u -p -r1.282 SConstruct
--- SConstruct 1 Sep 2005 22:04:46 -0000 1.282
+++ SConstruct 2 Sep 2005 12:35:24 -0000
vstEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
vstEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
guiProgramEnvironment.Prepend(LINKFLAGS = ['-mwindows',
'_CsoundVST.so'])
+ vstEnvironment.Append(LIBS = ['python2.3', 'dl', 'm'])
+ vstEnvironment.Append(CPPPATH = ['/usr/include/python2.3'])
+ vstEnvironment.Append(cxxflags = ['-fabi-version=0']) # if gcc3.2-3
+ vstEnvironment.Append(LIBPATH =
['/usr/lib64/python2.3/config'])
+ vstEnvironment.Append(LIBPATH = ['/usr/lib/python2.3/config'])
+ vstEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
+ vstEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
+ guiProgramEnvironment.Prepend(LINKFLAGS = ['_CsoundVST.so'])
pythonImportLibrary =
vstEnvironment.Command('/usr/local/lib/libpython23.a',
'$SYSTEMROOT/System32/python23.dll',
@@ -1216,6 +1227,15 @@ Opcodes/stk/src/Thread.cpp
pyEnvironment.Append(LIBPATH =
['/usr/local/lib/python2.3/config'])
pyEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
pyEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
+ pyEnvironment.Append(LIBS = ['python2.3', 'dl', 'm'])
+ pyEnvironment.Append(CPPPATH = ['/usr/include/python2.3'])
+ pyEnvironment.Append(LIBPATH = ['/usr/lib64/python2.3/config'])
+ pyEnvironment.Append(LIBPATH = ['/usr/lib/python2.3/config'])
+ pyEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
+ pyEnvironment.Append(SHLINKFLAGS = '--add-stdcall-alias')
pyEnvironment['ENV']['PATH'] = os.environ['PATH']
pyEnvironment.Append(SHLINKFLAGS = '--no-export-all-symbols')
Index: custom.py
===================================================================
RCS file: /cvsroot/csound/csound5/custom.py,v
retrieving revision 1.22
diff -u -p -r1.22 custom.py
--- custom.py 26 Jun 2005 01:23:15 -0000 1.22
+++ custom.py 2 Sep 2005 12:35:24 -0000
platform = 'cygwin'
customCPPPATH.append('c:/utah/usr/Python23/include')
+ platform = 'darwin'
+ customCPPPATH.append('/usr/include/malloc')
+ customCPPPATH.append('/opt/local/include/boost-1_32/')
+ customCPPPATH.append('/usr/include/python2.3')
+ customCXXFLAGS.append('-fabi-version=0')
# For the basic build you need MinGW, MSys, and libsndfile.
Index: frontends/CsoundVST/CsoundVSTMain.cpp
===================================================================
RCS file: /cvsroot/csound/csound5/frontends/CsoundVST/CsoundVSTMain.cpp,v
retrieving revision 1.6
diff -u -p -r1.6 CsoundVSTMain.cpp
--- frontends/CsoundVST/CsoundVSTMain.cpp 28 May 2005 13:00:07
-0000 1.6
+++ frontends/CsoundVST/CsoundVSTMain.cpp 2 Sep 2005 12:35:24 -0000
@@ -36,7 +36,7 @@ bool oome = false;
#if defined(__GNUC__) && defined(WIN32)
#define main main_plugin
extern "C" __declspec(dllexport) AEffect *main_plugin
(audioMasterCallback audioMaster)
-#elif defined(LINUX)
+#elif defined(LINUX) || defined(MACOSX)
AEffect *main_plugin (audioMasterCallback audioMaster)
#else
AEffect *main(audioMasterCallback audioMaster)
Index: frontends/CsoundVST/AEffect.h
===================================================================
RCS file: /cvsroot/csound/csound5/frontends/CsoundVST/AEffect.h,v
retrieving revision 1.5
diff -u -p -r1.5 AEffect.h
--- frontends/CsoundVST/AEffect.h 28 May 2005 13:00:07 -0000 1.5
+++ frontends/CsoundVST/AEffect.h 2 Sep 2005 12:35:26 -0000
@@ -20,7 +20,7 @@
long value, void *ptr, float opt));
*/
-#if CARBON
+#if CARBON || MACOSX
#if PRAGMA_STRUCT_ALIGN || __MWERKS__
#pragma options align=mac68k
#endif
@@ -178,7 +178,7 @@ enum
// will always return true.
};
-#if CARBON
+#if CARBON || MACOSX
#if PRAGMA_STRUCT_ALIGN || __MWERKS__
#pragma options align=reset
#endif
Index: frontends/CsoundVST/System.cpp
===================================================================
RCS file: /cvsroot/csound/csound5/frontends/CsoundVST/System.cpp,v
retrieving revision 1.16
diff -u -p -r1.16 System.cpp
--- frontends/CsoundVST/System.cpp 26 Aug 2005 17:47:54 -0000 1.16
+++ frontends/CsoundVST/System.cpp 2 Sep 2005 12:35:29 -0000
@@ -698,7 +698,7 @@ namespace csound
beep();
}
-#elif defined(LINUX)
+#elif defined(LINUX) || defined(MACOSX)
#include <dlfcn.h>
#include <dirent.h>
Index: InOut/window.c
===================================================================
RCS file: /cvsroot/csound/csound5/InOut/window.c,v
retrieving revision 1.14
diff -u -p -r1.14 window.c
--- InOut/window.c 12 Aug 2005 19:01:23 -0000 1.14
+++ InOut/window.c 2 Sep 2005 12:35:31 -0000
@@ -40,11 +40,13 @@ static void (*killFn)(CSOUND *, WINDAT *
extern void KillAscii(CSOUND *, WINDAT *);
extern void KillGraph(CSOUND *, WINDAT *);
/* pointer to xyinput window creator */
- void (*mkxyFn)(CSOUND *, XYINDAT *, MYFLT, MYFLT);
+/* globals must have a value assigned in OSX */
+/* c.f. http://wiki.tcl.tk/2923 */
+ void (*mkxyFn)(CSOUND *, XYINDAT *, MYFLT, MYFLT) = NULL;
static void MkXYDummy(CSOUND *, XYINDAT *, MYFLT, MYFLT);
extern void MakeXYin(CSOUND *, XYINDAT *, MYFLT, MYFLT);
/* pointer to xyinput window reader */
- void (*rdxyFn)(CSOUND *, XYINDAT *);
+ void (*rdxyFn)(CSOUND *, XYINDAT *) = NULL;
static void RdXYDummy(CSOUND *, XYINDAT *);
extern void ReadXYin(CSOUND *, XYINDAT *);
Index: OOps/aops.c
===================================================================
RCS file: /cvsroot/csound/csound5/OOps/aops.c,v
retrieving revision 1.43
diff -u -p -r1.43 aops.c
--- OOps/aops.c 26 Aug 2005 17:47:53 -0000 1.43
+++ OOps/aops.c 2 Sep 2005 12:35:35 -0000
@@ -33,7 +33,8 @@
#define ONEdLOG2 (1.4426950408889634074)
/* static lookup tables, initialised once at start-up */
- MYFLT cpsocfrc[OCTRES];
+/* dummy initialization for OSX, c.f. http://wiki.tcl.tk/2923 */
+ MYFLT cpsocfrc[OCTRES] = {};
static MYFLT powerof2[4096];
/* initialise the tables, called by csoundInitialize() */

Michael Gogins

2005-09-02 13:39:01 UTC

Permalink

If you don't mind, I would prefer it if you send me your complete SConstruct (to ***@pipeline.com) and I will merge it. Same for any source code changes that needed to make -- I prefer complete files.

Regards,
Mike

-----Original Message-----
From: Graham Breed <***@gmail.com>
Sent: Sep 2, 2005 8:50 AM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Csound 5 status

Post by Michael Gogins
You need to make sure the directory where _CsoundVST.so or whatever is located, is identified in your PYTHONPATH environment variable. I have a feeling this may do the job.

Istvan Varga

2005-09-02 13:58:23 UTC

Permalink

I already started merging the patch.

Post by Michael Gogins
If you don't mind, I would prefer it if you send me your complete
any source code changes that needed to make -- I prefer complete files.

Andres Cabrera

2005-09-23 03:31:20 UTC

Permalink

Hi,
About this message I remembered today something that was discussed that
may be worth looking at, which is the addition of opcode meta-data.
It might be useful (especially for front-ends and programs that use the
api) to be able to know some more information about the opcodes. It
would be good if apart from having access to the input and output number
and types, having some other information like:
-descriptive names for input and output variables (eg. aout, kfreq,
etc.)
-Brief (one line) description of the opcodes's function
-Category and sub-category, for front-ends to be able to generate help
and context menus (among other things). I'm thinking specifically of
blue's menu to choose opcodes.

This way, programs like blue or cecilia could generate part of their
documentation dynamically, directly from the opcodes themselves.

Does this proposal make sense?
I would dig in if I knew where to start, but I can offer help in adding
the information to the opcode sources.

Cheers,
Andres

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Anthony Kozar

2005-09-23 05:17:20 UTC

Permalink

Post by Andres Cabrera
Hi,
About this message I remembered today something that was discussed that
may be worth looking at, which is the addition of opcode meta-data.

[...]

Post by Andres Cabrera
This way, programs like blue or cecilia could generate part of their
documentation dynamically, directly from the opcodes themselves.
Does this proposal make sense?

YES! Thank you! This really is necessary.

Post by Andres Cabrera
I would dig in if I knew where to start, but I can offer help in adding
the information to the opcode sources.

That would be great. I wish that I really had the time right now to commit
to this myself, to make sure that it gets done.

Post by Andres Cabrera

- BUG: line continuation ('\') does not work with non-native line endings?

Is this sure ?

I've seen this in Csound 4 on MacOS 9 when using an orchestra with DOS line
endings. Csound reads a \r\n as TWO lines following the \ and assumes the
continuation is finished. The problem likely still exists in Csound 5 and I
am guessing that it affects Unix platforms as well.

Post by Andres Cabrera
Perhaps those people who made fixes to version 4 but not 5 (knowing
that the former will eventually be deprecated in favor of the latter)
should port their fixes now, rather than having others hunt for
every little and possibly undocumented change ?

Yes, we should! But, oh, to find the time and the will ...

Post by Andres Cabrera

- be able to print a list of installed plugins and what functionality
each provides. (This is critical for usability as I see it).

While currently there is no API function that lists the loaded plugins,
it should be easy to implement because there is a database of loaded
libraries (note that the directory part of the file names is not preserved).
Knowing the functionality of the plugins would require changes to the plugins
themselves to return "plugin type" information that should be stored in the
database.
I am not sure, however, if this is critical for usability, as so far no one
else asked for this functionality.

Matt and I have discussed this before. The problem we envision after Cs5 is
released and many plugins become available from mulitple sources is that
users will find it difficult to know what they have installed in their own
systems.

Let's face it, people forget things or they don't fully understand what they
are installing in the first place. Or they are not sure which version they
have installed, etc, etc.

The problem comes when a user tries to "clean out" their opcode directory
because it is getting large and unwieldy. (The time to load a dynamic
library is not insignificant!) How do they know what they need to keep and
what they can safely throw away? Which ones are opcode libraries, fgen
libraries, and real-time audio or midi interfaces? How do they figure out
what opcodes are supplied by which libraries? How do they tell the
difference between a library that is for 32-bit floats and one that is for
64-bit floats? etc.

I think this is definitely a usability issue and I believe that it is one
that can be solved by the development team. Csound should be able to ask
plugins these questions and receive answers, then organize and format the
information to output in a manner that the user can understand and use.

Just my $.02 ...

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Istvan Varga

2005-09-23 09:07:19 UTC

Permalink

Post by Anthony Kozar
I've seen this in Csound 4 on MacOS 9 when using an orchestra with DOS line
endings. Csound reads a \r\n as TWO lines following the \ and assumes the
continuation is finished. The problem likely still exists in Csound 5 and I
am guessing that it affects Unix platforms as well.

So, did you actually test it, or not ? Some people do actually make
changes to the sources, so the bug may possibly be fixed now.

Post by Anthony Kozar

Yes, we should! But, oh, to find the time and the will ...

Well, then perhaps the changes should have been made to Csound 5 in
the first place. Anyway, many of the fixes may have been applied to
version 5 as well, although in a different way.

Post by Anthony Kozar
Matt and I have discussed this before. The problem we envision after Cs5 is
released and many plugins become available from mulitple sources is that
users will find it difficult to know what they have installed in their own
systems.
Let's face it, people forget things or they don't fully understand what they
are installing in the first place. Or they are not sure which version they
have installed, etc, etc.
The problem comes when a user tries to "clean out" their opcode directory
because it is getting large and unwieldy. (The time to load a dynamic
library is not insignificant!) How do they know what they need to keep and
what they can safely throw away? Which ones are opcode libraries, fgen
libraries, and real-time audio or midi interfaces? How do they figure out
what opcodes are supplied by which libraries? How do they tell the
difference between a library that is for 32-bit floats and one that is for
64-bit floats? etc.
I think this is definitely a usability issue and I believe that it is one
that can be solved by the development team. Csound should be able to ask
plugins these questions and receive answers, then organize and format the
information to output in a manner that the user can understand and use.

Checking for MYFLT type and API version as well is already supported,
so plugins of incompatible floating point type or interface version are
rejected (assuming that the plugin does provide this information, but
it is included with the LINKAGE macro that is most commonly used in
opcode libraries).
Most of the other ideas are not fully clear, and I do not like the idea
of integrating parts of the manual into the engine or plugins; is there
any reason why the frontends cannot to display pages from the actual
manual ?

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Anthony Kozar

2005-09-23 16:10:51 UTC

Permalink

Post by Istvan Varga
Most of the other ideas are not fully clear, and I do not like the idea
of integrating parts of the manual into the engine or plugins; is there
any reason why the frontends cannot to display pages from the actual
manual ?

Yes. When lots of people start distributing many Csound plugins for a
multitude of sites, there will be no combined manual for all of them. This
is why the plugins need to embed some metadata about themselves -- so that
hosts can provide users with a decent interface to all of this information.

We cannot assume one central repository for all Csound plugins. If someone
does not believe me on this, just search the web for PD internals.

Anthony

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Istvan Varga

2005-09-23 17:15:53 UTC

Permalink

Post by Anthony Kozar
Yes. When lots of people start distributing many Csound plugins for a
multitude of sites, there will be no combined manual for all of them. This
is why the plugins need to embed some metadata about themselves -- so that
hosts can provide users with a decent interface to all of this information.
We cannot assume one central repository for all Csound plugins. If someone
does not believe me on this, just search the web for PD internals.

While it does not seem like many people are about to write Csound plugins,
I think the plugin packages may very well include documentation such as
opcode manuals.
I still do not like the idea of having to embed documentation for every single
opcode into the source code, but if there is enough demand, well... I assume
there is someone who will go through all the more than 1000 opcodes and make
the changes, right ?

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

David Akbari

2005-09-23 17:56:09 UTC

Permalink

Post by Anthony Kozar
Yes. When lots of people start distributing many Csound plugins for a
multitude of sites, there will be no combined manual for all of them.
This
is why the plugins need to embed some metadata about themselves -- so that
hosts can provide users with a decent interface to all of this information.
We cannot assume one central repository for all Csound plugins. If someone
does not believe me on this, just search the web for PD internals.

How about the idea of having a string database compiled at build time
with a particular Csound distribution? (Like English.xmg but it
contains the equivalent output of csound -z1 and is made at build time
reflecting all opcodes that were built)

I'm thinking of how Steven Yi's blue uses a file called opcodes.xml
which has a very simply implemented syntax (for users who could be
making their own plugins) and is loaded once at program initialization.

For blue specifically, the syntax is as follows:

<CsoundOpcodes>
<OpcodeGroup="GroupName">
<opcode>
<name>YourOpcodeName</name>
<signature>outtype YourOpcodeName inarg1, [ ioptarg1 ]</signature>
</opcode>
[ ... more opcode data here ]
</OpcodeGroup>
[ ... more groups here ]
</CsoundOpcodes>

Using this type of XML based syntax keeps the idea of an "opcode
metadata database" separate from the API and processing functions of
Csound and in addition the syntax should be clear for anyone who can at
least read and understand what a unified .csd file is. This approach is
also easily appended by a user who desires to add opcodes. For example
it was no problem to update Blue's menus to reflect the current status
of canonical Csound5.

Another idea is to have exactly an XML of all Opcode metadata that is
part of the canonical manual CVS so that users checking out the manual
module from CVS can also build the Opcode metadata string database in
addition to docbook, PDF, HTML etc The syntax of this type of XML would
of course not be implemented as above but be a reflection of the proper
way to add elements to the manual.

-David

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Andres Cabrera

2005-09-24 13:11:46 UTC

Permalink

Istvan,

I am willing (after my honeymoon in October) =) to go through the 1000
opcodes and do this. I cannot help with setting up the system, but I can
help adding the information for the opcodes.
I still think the idea needs to be discussed, I'm only proposing, but I
don't really know if it has any negative implications apart from the
initial work involved.

Cheers,
Andrés

Post by Istvan Varga

While it does not seem like many people are about to write Csound plugins,
I think the plugin packages may very well include documentation such as
opcode manuals.
I still do not like the idea of having to embed documentation for every single
opcode into the source code, but if there is enough demand, well... I assume
there is someone who will go through all the more than 1000 opcodes and make
the changes, right ?
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Russell Johnston

2005-09-24 13:23:50 UTC

Permalink

I'd be happy to put some time into the grunt work part of this, once
a format/design for the task emerges. It shouldn't be too hard to
divide up the opcodes if a few people can pitch in, right?

Russell

Post by Istvan Varga

Post by Anthony Kozar
Yes. When lots of people start distributing many Csound plugins for a
multitude of sites, there will be no combined manual for all of them.
This
is why the plugins need to embed some metadata about themselves -- so that
hosts can provide users with a decent interface to all of this information.
We cannot assume one central repository for all Csound plugins. If someone
does not believe me on this, just search the web for PD internals.

While it does not seem like many people are about to write Csound plugins,
I think the plugin packages may very well include documentation such as
opcode manuals.
I still do not like the idea of having to embed documentation for every single
opcode into the source code, but if there is enough demand, well... I assume
there is someone who will go through all the more than 1000 opcodes and make
the changes, right ?
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

2005-09-24 13:38:20 UTC

Permalink

Other than the idea of integrating parts of the manual into the
source that I oppose, are there any suggested changes ?
It is really amazing that other than the idea of replacing CSOUND
with a C++ class, I still did not get a single comment on the API.
Minor but incompatible changes that clean up the interface should
be done now, before the release (which unfortunately seems to become
very unlikely this year, or maybe even the next year, as things
are now).

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Richard Dobson

2005-09-24 16:54:05 UTC

Permalink

This brings up the "query-interface" system I suggested a while back - the
plugin ~may~ provide a documentation page, and the host can simply
Query-Interface on the plugin for an "IXMLDocPage" object, pointer or whatever.
If there is one, the host app can display it; if not the user has to seek
elsewhere for info, in the time-honoured way.

In short, this is an either/or model, rather than an all/nothing model. If
offers both host and plugin authors the choice. I suspect it is unlikely that
this would be the last or most complex possible addition to a plugin, so that
the query-interface system offers a degree of flexibilty and future-proofness,
and takes us away from the old paradigm of "everything must be hard-coded".

Hmm, how about a plugin that can provide a URL to the web page from whence
updates to that plugin can be obtained?

Richard Dobson

Post by Istvan Varga
While it does not seem like many people are about to write Csound plugins,
I think the plugin packages may very well include documentation such as
opcode manuals.
I still do not like the idea of having to embed documentation for every single
opcode into the source code, but if there is enough demand, well... I assume
there is someone who will go through all the more than 1000 opcodes and make
the changes, right ?

Matt Ingalls

2005-09-24 17:43:26 UTC

Permalink

sounds good --

Max has a nice feature where you can option-click on any object and a
"help"
patch will open up showing an example. maybe adding a "help" .csd
mechanism
would be good as well?

In addition, and i think this might have already been suggested on
this list
[ i just can't keep up! ]

what i think would be REALLY nice is have the syntax in the OENTRY
struct.
so in addition to the i/o definitions you would have another field
for human consumption like:

{ "myopcode", S(MYOPCODE), 5, "aa","aki",(SUBR)MyOpcodeInit, NULL,
(SUBR)MyOpcode, "aout1, aout2 myopcode asig, kpitch, itable"},

so that editor-hosts could call csoundNewOpcodeList() and be able to
display the syntax
of an opcode to the user. it could also be used in csound kernel
when displaying orc-processing error messages,

-m

Post by Richard Dobson
This brings up the "query-interface" system I suggested a while
back - the plugin ~may~ provide a documentation page, and the host
can simply Query-Interface on the plugin for an "IXMLDocPage"
object, pointer or whatever. If there is one, the host app can
display it; if not the user has to seek elsewhere for info, in the
time-honoured way.
In short, this is an either/or model, rather than an all/nothing
model. If offers both host and plugin authors the choice. I suspect
it is unlikely that this would be the last or most complex possible
addition to a plugin, so that the query-interface system offers a
degree of flexibilty and future-proofness, and takes us away from
the old paradigm of "everything must be hard-coded".
Hmm, how about a plugin that can provide a URL to the web page from
whence updates to that plugin can be obtained?
Richard Dobson

Post by Istvan Varga
While it does not seem like many people are about to write Csound plugins,
I think the plugin packages may very well include documentation such as
opcode manuals.
I still do not like the idea of having to embed documentation for every single
opcode into the source code, but if there is enough demand,
well... I assume
there is someone who will go through all the more than 1000
opcodes and make
the changes, right ?

-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Matt;
________________________
matt ingalls
http://sonomatics.com

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Steven Yi

2005-09-23 17:47:18 UTC

Permalink

Hi All,

Something sounds not right about embedding documentation as well.
Would it not be possible for csound to have a manual lookup system and
a separate directory full of manual entries? It would make easier
updating of manual entries to have them separate, so if an manual is
updated, the opcode doesn't have to be recompiled and redistributed.
The precedent I am thinking about is the unix man pages, where the
utility and man page are separate.

What features would be interesting I think:

-If csound experiences an error in orchestra code, to check the manual
directory for an entry for the failed opcode, and if it finds it,
parse out the command line text from it, thus able to give a more
descriptive explanation, but if it doesn't find the error, report as
it does now

-for csound -z and -z1, also do a lookup of the manual entry and do
the same, show if available and use old method if not (maybe make this
-z2)

I can try to mock up something in python to do the lookup. What this
doesn't do is allow for grouping of entries. It might be nice to have
a string category in the OENTRY to facilitate that, but it could also
simply be done in the manual entry too.

steven

Post by Anthony Kozar

Yes. When lots of people start distributing many Csound plugins for a
multitude of sites, there will be no combined manual for all of them. This
is why the plugins need to embed some metadata about themselves -- so that
hosts can provide users with a decent interface to all of this information.
We cannot assume one central repository for all Csound plugins. If someone
does not believe me on this, just search the web for PD internals.
Anthony
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Andres Cabrera

2005-09-24 17:27:36 UTC

Permalink

Hi Steven,
I like these ideas. Maybe it's possible to reuse the current manual
sources syntax, to simplify the process of adding already existing
opcodes?
<synopsis>ares <command>oscil</command> xamp, xcps, ifn [,
iphs]</synopsis>
Maybe a new variable called something like CSDOCDIR would be necessary?

Cheers,
Andrés

Post by Steven Yi
Hi All,
Something sounds not right about embedding documentation as well.
Would it not be possible for csound to have a manual lookup system and
a separate directory full of manual entries? It would make easier
updating of manual entries to have them separate, so if an manual is
updated, the opcode doesn't have to be recompiled and redistributed.
The precedent I am thinking about is the unix man pages, where the
utility and man page are separate.
-If csound experiences an error in orchestra code, to check the manual
directory for an entry for the failed opcode, and if it finds it,
parse out the command line text from it, thus able to give a more
descriptive explanation, but if it doesn't find the error, report as
it does now
-for csound -z and -z1, also do a lookup of the manual entry and do
the same, show if available and use old method if not (maybe make this
-z2)
I can try to mock up something in python to do the lookup. What this
doesn't do is allow for grouping of entries. It might be nice to have
a string category in the OENTRY to facilitate that, but it could also
simply be done in the manual entry too.
steven

Post by Anthony Kozar

Yes. When lots of people start distributing many Csound plugins for a
multitude of sites, there will be no combined manual for all of them. This
is why the plugins need to embed some metadata about themselves -- so that
hosts can provide users with a decent interface to all of this information.
We cannot assume one central repository for all Csound plugins. If someone
does not believe me on this, just search the web for PD internals.
Anthony
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Anthony Kozar

2005-09-25 01:02:21 UTC

Permalink

I don't think that I like this idea of using a markup language with the
metadata. Who does the job then of parsing it? Will every host have to
write its own parsing code?

What I had in mind was much closer to the ideas just posted by Richard and
Matt today. Richard's "Query Interface" -- if I understand correctly --
would provide methods for asking for labeled pieces of data. If the data
does not exist for a particular opcode or plugin then some kind of a "NULL"
answer should be returned.

I was imagining the labels as integer constants defined by an enumeration in
one of the Csound headers. But they could also be text strings, I suppose.
The important thing would be for every plugin to have code to return NULL if
it does not recognize a label. And certain common pieces of metadata --
such as the opcode syntax, brief opcode description, purpose of a plugin,
etc. -- should be advertised as very important to include in the docs for
plugin/opcode writers.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/

Post by Andres Cabrera
Hi Steven,
I like these ideas. Maybe it's possible to reuse the current manual
sources syntax, to simplify the process of adding already existing
opcodes?
<synopsis>ares <command>oscil</command> xamp, xcps, ifn [,
iphs]</synopsis>

Michael Gogins

2005-09-23 12:31:13 UTC

Permalink

I think this is a good idea. I would urge you to google around a bit and see
how others might have handled this problem. My initial idea would be to
embed the help in the opcode shared library file as a static string as
either plain text, or in some minimal XML or HTML format.

Regards,
Mike

----- Original Message -----
From: "Andres Cabrera" <***@geminiflux.com>
To: "Csound-dev" <csound-***@lists.sourceforge.net>
Sent: Thursday, September 22, 2005 11:31 PM
Subject: [Cs-dev] Re: [Csnd] Csound 5 status

Post by Andres Cabrera
Hi,
About this message I remembered today something that was discussed that
may be worth looking at, which is the addition of opcode meta-data.
It might be useful (especially for front-ends and programs that use the
api) to be able to know some more information about the opcodes. It
would be good if apart from having access to the input and output number
-descriptive names for input and output variables (eg. aout, kfreq,
etc.)
-Brief (one line) description of the opcodes's function
-Category and sub-category, for front-ends to be able to generate help
and context menus (among other things). I'm thinking specifically of
blue's menu to choose opcodes.
This way, programs like blue or cecilia could generate part of their
documentation dynamically, directly from the opcodes themselves.
Does this proposal make sense?
I would dig in if I knew where to start, but I can offer help in adding
the information to the opcode sources.
Cheers,
Andres

Michael Gogins

2005-09-24 15:47:33 UTC

Permalink

Istvan, what do you think needs to be done before a release?

I did have another suggestion which I will repeat, getting a Python binding to run Csound, create and edit scores, and so on into the non-CsoundVST version of csound 5. As I see it, the main obstacle to just moving CsoundVST into csound5's main library is the boost stuff in the algorithmic composition classes.

My questions are:

Do all the utilities run in 32 and 64 bits? I only care if they run inside Csound, I don't care about the standalone invocation.

Is there anything we can do to get FLTK working simultaneously for Ftable display and for FLTK widgets?

-----Original Message-----
From: Istvan Varga <***@fibermail.hu>
Sent: Sep 24, 2005 9:38 AM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Other than the idea of integrating parts of the manual into the
source that I oppose, are there any suggested changes ?
It is really amazing that other than the idea of replacing CSOUND
with a C++ class, I still did not get a single comment on the API.
Minor but incompatible changes that clean up the interface should
be done now, before the release (which unfortunately seems to become
very unlikely this year, or maybe even the next year, as things
are now).

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

David Akbari

2005-09-24 16:54:14 UTC

Permalink

Post by Michael Gogins
Is there anything we can do to get FLTK working simultaneously for
Ftable display and for FLTK widgets?

Seems to work fine on OSX ... here's a screenshot of one of Art
Hunkins' latest pieces:

http://www.csounds.com/akbari/AngelDervish.pdf

I'd also like to add that -g is really a drag when doing Scanned
Synthesis!

-d is much better in that case ... but the FLTK looks nice for, say a
demonstration in a classroom setting.

-David

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

j***@codemist.co.uk

2005-09-24 18:01:02 UTC

Permalink

I cannot see that there are many things stopping a csound5.0rc1
The list I had is almost complete
------------------------------------------------------------------------
KNOWN AREAS OF INCOMPLETENESS
-----------------------------

K1. There is no looping structures for aiff (or wav) files

K2. Parser

K7. Installer for MacOSX

BUGS NOT FIXED
--------------

B1. hetro and lpanal are broken

B2. Many differences between FL code on Csound and CsoundAV

DOCUMENTATION
-------------

<<
lpsholdp
seqtime2
tab
tab_i
tabplay
tabrec
tabw
tabw_i
tb0 ... tb15
tb0_init ... tb15_init
timedseq
cogoto
pvsifd : streaming spectral analysis using the IFD
partials : partial track analysis from a streaming PV input
tradsyn : additive synthesis of tracks (linear interpolation)
sinsyn : additive synthesis (cubic phase)
resyn : additive synthesis (cubic phase, adapted for transformed
signals)
------------------------------------------------------------------------

The biggest area is documentation. I like Richard's suggestion of a
plugin call to give the URL of the documentation, or no link. The
things I know about not included above are:

Simple Installers for all platforms
Integration of SDFT into the f-signals
Replacing the control opcode with something as simple
I still have FLTK problems on MacOSX

I think we really need a release candidate, and this month.

==John ffitch

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Istvan Varga

2005-09-25 10:35:04 UTC

Permalink

Post by Michael Gogins
Istvan, what do you think needs to be done before a release?

I do not really have many ideas at this time, and that is one
of the reasons why I keep asking if anyone else does.
Currently, one unfinished project is the bus interface, but
it seems from the relative lack of comments that there is not
much interest or demand for it; so, I may consider removing it
for now, keeping only the two opcodes 'chnget' and 'chnset' for
private use by the orchestra, but no API functions or extra
features.
Another issue is replacing the use of rand() in various opcodes
with an API function that generates random numbers in a more
portable way, and without the problems associated with rand()
when used from multiple instances at the same time. This is not
really important, but it changes the output of the opcodes, so
is better done before the release.
It may also be worth to clean up the use of temporary files,
but this is a low priority issue too.
What is definitely to be done before a release is finishing
the API so that all incompatible changes (even if something
minor like renaming functions, changing the layout of structures,
etc.) are done now. As there are no comments on this issue,
it is tempting to leave everything as it is, but I am afraid
that people will start to complain when the interface is already
considered frozen and thus it is too late.
I still do not have plans on changes related to the "plugin
metadata" issue, because all the ideas so far are ones that I
either do not like, require too much changes, or are just not
sufficiently well defined to implement.

Post by Michael Gogins
I did have another suggestion which I will repeat, getting a
Python binding to run Csound, create and edit scores, and so on
into the non-CsoundVST version of csound 5. As I see it, the main
obstacle to just moving CsoundVST into csound5's main library is
the boost stuff in the algorithmic composition classes.

But why is it absolutely necessary to integrate CsoundVST into
libcsound ? I prefer having the library small and simple with as
few compile problems and external dependencies as possible;
CsoundVST - or anything else - can always just wrap the main
library.

Post by Michael Gogins
Do all the utilities run in 32 and 64 bits? I only care if they
run inside Csound, I don't care about the standalone invocation.

In most cases, it does not matter if the utilities are running from
csound (with -U) or as standalone, because almost all (with the
possible exception of some rarely used ones) have already been
converted to plugins. I think the more important utilities should
work using both 32 and 64 bit floats, but if you find one that
does not, then it should not be hard to fix the bug.

Post by Michael Gogins
Is there anything we can do to get FLTK working simultaneously
for Ftable display and for FLTK widgets?

I would prefer moving the FLTK table displays out of the engine
as well, leaving only the old ASCII and PostScript code as built-in.
It may be possible to integrate the display and widget code into
a single plugin that uses the API calls to register all the MakeGraph
and other functions, and having all FLTK stuff in one place again
might allow for easier fixing of the problems related to using
displays and widgets at the same time.
Also, not having FLTK displays in the main library means no
dependencies on FLTK or C++ at all, and the functions related to
FLTK locking could be removed from the API as well. I do not know,
though, if this is a problem for CsoundVST that also uses FLTK.

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Michael Gogins

2005-09-25 11:05:24 UTC

Permalink

To start with, I really, really appreciate all the excellent work you have
put into Csound.

The bus interface permits external software (API clients) to directly get
and set Csound variables -- is that correct? If so I think it is a very good
idea, but the word 'bus' is misleading.

I suggest replacing rand() with csound_rand() -- either Whittle's code or
the Mersenne Twister (I would prefer the latter since I think it is more
random and I think we can afford the small additional overhead). Perhaps it
could be an option to the opcode, which implementation to use.

I am not trying to get CsoundVST as a whole into libcsound, precisely for
the reason you cite -- increased dependencies. I am only trying to get a
Python wrapping for libcsound into libcsound. No boost or FLTK!

The Python dependency already exists in the build system for those who build
Csound, and for those who not have Python, the interface code will just sit
there and do nothing. It should not prevent libcsound from either linking or
running on systems that do not have Python.

The reason for this is that my compositional productivity with Python has
been significantly higher coding in Python than in any other language I've
used, and I'd like to see this benefit made more accessible for other
csounders. Plus, Python has a truly rich set of libraries that would add
significantly to what can be done with Csound.

If this were done, I might be able to factor stuff out of CsoundVST so it
would be easier to use it as the default FLTK user interface for Csound
(i.e., no "Silence" classes or boost). My algo-comp stuff would go into a
separate, independent Python extension.

I know people might say you can code scores in Python and just exec Csound,
but that's what I used to do, and the way I work now is a lot better.
Keeping track of one file per piece instead of 2 or 3 files ends up making a
lot of difference in terms of production efficiency.

After thinking about plugin metadata, I think it is a bad idea. It is better
to define a standard directory structure and format, consistent with the
existing excellent manual, for more extensive plugin documentation. It
should be the case that when users install plugins, they can rebuild the
manual and the plugin pages automatically get built into the manual. If
that's too hard, then a standard HTML format for plugin pages should be
defined, consistent with the manual. Some Javascript should enable a kind of
integration with the existing manual.

I like the idea of moving FLTK graphs into a plugin for FLTK. I do not know
if this creates a problem for CsoundVST. Probably, if the plugin has the
right kind of event loop and thread locking, it should be possible to
transfer the event loop to the plugin when CsoundVST is running, and get it
back when Csound is finished, or something. As long as there is a Csound
yield API this should all be doable.

Regards,
Mike

----- Original Message -----
From: "Istvan Varga" <***@fibermail.hu>
To: <csound-***@lists.sourceforge.net>
Sent: Sunday, September 25, 2005 6:35 AM
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Post by Istvan Varga

Post by Michael Gogins
Istvan, what do you think needs to be done before a release?

Post by Michael Gogins
Do all the utilities run in 32 and 64 bits? I only care if they
run inside Csound, I don't care about the standalone invocation.

Post by Michael Gogins
Is there anything we can do to get FLTK working simultaneously
for Ftable display and for FLTK widgets?

I would prefer moving the FLTK table displays out of the engine
as well, leaving only the old ASCII and PostScript code as built-in.
It may be possible to integrate the display and widget code into
a single plugin that uses the API calls to register all the MakeGraph
and other functions, and having all FLTK stuff in one place again
might allow for easier fixing of the problems related to using
displays and widgets at the same time.
Also, not having FLTK displays in the main library means no
dependencies on FLTK or C++ at all, and the functions related to
FLTK locking could be removed from the API as well. I do not know,
though, if this is a problem for CsoundVST that also uses FLTK.
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

2005-09-25 11:31:25 UTC

Permalink

Post by Michael Gogins
The bus interface permits external software (API clients) to directly
get and set Csound variables -- is that correct?

Yes, although the variable is not accessed by its name, but is rather
exported by the orchestra as a channel of the bus, for example:

/* orchestra header */

gaOutL chnexport "AudioOutput_Left", 2

/* C code in host */

CSOUND *csound;
MYFLT *buf;
...
if (csoundCompile(csound) != 0)
error();
if (csoundGetChannelPtr(csound, &buf, "AudioOutput_Left",
CSOUND_AUDIO_CHANNEL | CSOUND_OUTPUT_CHANNEL)
!= 0)
error();
/* now ksmps MYFLT values can be read from buf after every call to */
/* csoundPerformKsmps(), and buf actually points directly to the */
/* data of gaOutL */

I can also post a more complete example of a simple host and CSD
file.

Post by Michael Gogins
If so I think it is a very good idea, but the word 'bus' is misleading.

I am still not sure about the details (including names), so any
suggestions are welcome (more information about the current interface
is included below, quoted from an earlier post).

Post by Michael Gogins
I like the idea of moving FLTK graphs into a plugin for FLTK. I do not
know if this creates a problem for CsoundVST. Probably, if the plugin
has the right kind of event loop and thread locking, it should be
possible to transfer the event loop to the plugin when CsoundVST is
running, and get it back when Csound is finished, or something. As long
as there is a Csound yield API this should all be doable.

And how about these functions ? Is it important to keep them ?

PUBLIC void csoundSetFLTKThreadLocking(CSOUND *, int isLocking);
PUBLIC int csoundGetFLTKThreadLocking(CSOUND *);

-------------------------------------------------------------------------

Post by Michael Gogins
I am a little confused about all the modes and why you might want all
those options, but I only read enough of the email to do a test of the
encapsulated instrument, and will look into it a bit more.
As for linear/exponential, etc., those seem like things that should be
handled by the code before and after going through the channels, yes?
Seems like it might limit the purpose of the bus.

As I already mentioned, I am not sure about the channel metadata,
so it may be changed significantly if requested, or it may even be
removed completely. Generally, the information on input/output direction,
unknown/integer/linear/exponential control type, default, minimum,
and maximum control value are only hints that can be used by the host
application to allow the user to connect channels of the bus to some
external ports. For example, knowing that a control channel named
"FilterFrequency" is expected to receive input, has an exponential
scale, should be in the range 100 to 10000 with a default "normal"
setting of 1000, is useful for attaching a knob to that channel.
Basically, there are two types of metadata: the input/output bitmask
is always present, and if a new query of the channel is made with an
inconsistent bitmask, it is simply updated using bitwise OR:

asig chnget "foo" ; creates channel, with input bit set
chnset asig, "foo" ; this will set output too, so mode is now 3

The other type of metadata is optional and is for control channels only,
it provides information on the expected range of the control data; the
parameters included are "type" (unknown, integer, linear, exponential),
"default value", "minimum value", and "maximum value".

All these additional parameters are only relevant if you intend to use
this system for implementing communication between the orchestra and
the host application (as an alternative to invalue/outvalue).
If all you need is "named ZAK", accessed only from the orchestra, then
using only chnset and chnget should be fine, without caring about the
rest of the opcodes or the various special parameters (they do make
the channel lookup somewhat slower, though, so that may be one reason
to remove all support for metadata).

Post by Michael Gogins
As for chn_k, I'm a little confused on itype for that opcode, as it
would seem to me by its nature it's going to be a control signal.

itype for chn_k selects an optional "sub-type" for the control channel,
which can also be changed by a later chn_k call.

itype = 0

generic control channel (idflt, imin, and imax are ignored),
with no information on the range of the data

itype = 1

the channel data is expected to be limited to integer values

itype = 2

the channel data is expected to have a linear scale

itype = 3

the channel data is expected to have an exponential scale

example (declarations in the orchestra header):

; name mode type default min max
gkamp chnexport "Amplitude", 1, 3, 0.5, 0.001, 1
gkampDB chnexport "Amplitude_DB", 1, 2, -6, -60, 0
gkfreq chnexport "Frequency", 1, 3, 440, 20, 20000
gknote chnexport "Note_Number", 1, 1, 60, 1, 127

Note again that all the parameters are only hints, and have no effect
at all on the actual use of the channel.

Post by Michael Gogins

There is an implementation of the opcodes and API functions in the CVS
sources now, so you can try it and suggest changes (probably many are
needed, but at least there is something to get started with).
The "casting" of types by opcodes, as requested by Steven Yi, is not
(yet) supported, however, it is possible to create channels from actual
orchestra variables, making it easier and more efficient to implement
communication between the orchestra and the host application.
Also, there is some "metadata" such as input/output direction, and
optional parameters for control channels (integer/linear/exponential
type, default, minimum, and maximum value); these probably need to be
changed too, or may be removed if not found to be useful.
OPCODES
ival chnget Sname
kval chnget Sname
aval chnget Sname
Sval chnget Sname
Read value from a channel (created if does not exist yet, with an initial
value of zero; otherwise, it must be of a compatible type).
chnset ival, Sname
chnset kval, Sname
chnset aval, Sname
chnset Sval, Sname
Write to a channel (created if does not exist yet; otherwise, it must be
of a compatible type).
chn_k Sname, imode[, itype, idflt, imin, imax]
Declare control channel. imode is a sum of 1 for input and 2 for output.
For more information on input/output mode and the optional arguments, see
the API function below.
chn_a Sname, imode
chn_S Sname, imode
Declare audio or string channel.
gival chnexport Sname, imode[, itype, idflt, imin, imax]
gkval chnexport Sname, imode[, itype, idflt, imin, imax]
gaval chnexport Sname, imode
gSval chnexport Sname, imode
Export a global variable as a channel of the bus that should not exist
before calling the opcode. Allows the host application to read or write
orchestra variables directly.
The parameters are the same as in the case of chn_k/chn_a/chn_S.
itype, imode, ictltype, idflt, imin, imax chnparams
Query parameters of a channel (if it does not exist, all returned values
channel data type (1: control, 2: audio, 3: string)
sum of 1 for input and 2 for output
special parameters for control channel only; if not available, all are
set to zero
API FUNCTIONS
/**
* Stores a pointer to the specified channel of the bus in *p,
* creating the channel first if it does not exist yet.
* 'type' must be the bitwise OR of exactly one of the following values,
* CSOUND_CONTROL_CHANNEL
* control data (one MYFLT value)
* CSOUND_AUDIO_CHANNEL
* audio data (csoundGetKsmps(csound) MYFLT values)
* CSOUND_STRING_CHANNEL
* string data (MYFLT values with enough space to store
* csoundGetStrVarMaxLen(csound) characters, including the
* NULL character at the end of the string)
* CSOUND_INPUT_CHANNEL
* CSOUND_OUTPUT_CHANNEL
* If the channel already exists, it must match the data type (control,
* audio, or string), however, the input/output bits are OR'd with the
* new value. Note that audio and string channels can only be created
* after calling csoundCompile(), because the storage size is not known
* until then.
* Return value is zero on success, or a negative error code,
* CSOUND_MEMORY there is not enough memory for allocating the channel
* CSOUND_ERROR the specified name or type is invalid
* or, if a channel with the same name but incompatible type already exists,
* the type of the existing channel. In the case of any non-zero return
* value, *p is set to NULL.
* Note: to find out the type of a channel without actually creating or
* changing it, set 'type' to zero, so that the return value will be either
* the type of the channel, or CSOUND_ERROR if it does not exist.
*/
PUBLIC int csoundGetChannelPtr(CSOUND *,
MYFLT **p, const char *name, int type);
/**
* Returns a list of allocated channels, storing a pointer to an array
* of channel names in *names, and a pointer to an array of channel types
* in *types. (*types)[n] corresponds to (*names)[n], and has the same
* format as the 'type' parameter of csoundGetChannelPtr().
* The return value is the number of channels, which may be zero if there
* are none, or CSOUND_MEMORY if there is not enough memory for allocating
* the lists. In the case of no channels or an error, *names and *types are
* set to NULL.
* Note: the caller is responsible for freeing the lists returned in *names
* and *types with free(), however, the actual channel names should not be
* changed or freed. Also, the name pointers may become invalid after calling
* csoundReset().
*/
PUBLIC int csoundListChannels(CSOUND *, char ***names, int **types);
/**
* type: must be one of CSOUND_CONTROL_CHANNEL_INT,
* CSOUND_CONTROL_CHANNEL_LIN, or CSOUND_CONTROL_CHANNEL_EXP for
* integer, linear, or exponential channel data, respectively,
* or zero to delete any previously assigned parameter information
* dflt: the control value that is assumed to be the default, should be
* greater than or equal to 'min', and less than or equal to 'max'
* min: the minimum value expected; if the control type is exponential,
* it must be non-zero
* max: the maximum value expected, should be greater than 'min';
* if the control type is exponential, it must be non-zero and
* match the sign of 'min'
* CSOUND_ERROR: the channel does not exist, is not a control channel,
* or the specified parameters are invalid
* CSOUND_MEMORY: could not allocate memory
*/
PUBLIC int csoundSetControlChannelParams(CSOUND *, const char *name,
int type, MYFLT dflt,
MYFLT min, MYFLT max);
/**
* Returns special parameters (assuming there are any) of a control channel,
* previously set with csoundSetControlChannelParams().
* If the channel exists, is a control channel, and has the special parameters
* assigned, then the default, minimum, and maximum value is stored in *dflt,
* *min, and *max, respectively, and a positive value that is one of
* CSOUND_CONTROL_CHANNEL_INT, CSOUND_CONTROL_CHANNEL_LIN, and
* CSOUND_CONTROL_CHANNEL_EXP is returned.
* In any other case, *dflt, *min, and *max are not changed, and the return
* value is zero if the channel exists, is a control channel, but has no
* special parameters set; otherwise, a negative error code is returned.
*/
PUBLIC int csoundGetControlChannelParams(CSOUND *, const char *name,
MYFLT *dflt, MYFLT *min, MYFLT *max);

Michael Gogins

2005-09-25 12:36:40 UTC

Permalink

I wouldn't use the metadata stuff myself, though others might, so it would
be OK for me to omit it. But in that case, is the 'bus' redundant with
existing facilities? Just having names is a definite plus, however. Even if
that's the only difference, it's worth doing.

Regards,
Mike

----- Original Message -----
From: "Istvan Varga" <***@fibermail.hu>
To: <csound-***@lists.sourceforge.net>
Sent: Sunday, September 25, 2005 7:31 AM
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Post by Istvan Varga

Post by Michael Gogins
The bus interface permits external software (API clients) to directly get
and set Csound variables -- is that correct?

Yes, although the variable is not accessed by its name, but is rather
/* orchestra header */
gaOutL chnexport "AudioOutput_Left", 2
/* C code in host */
CSOUND *csound;
MYFLT *buf;
...
if (csoundCompile(csound) != 0)
error();
if (csoundGetChannelPtr(csound, &buf, "AudioOutput_Left",
CSOUND_AUDIO_CHANNEL | CSOUND_OUTPUT_CHANNEL)
!= 0)
error();
/* now ksmps MYFLT values can be read from buf after every call to */
/* csoundPerformKsmps(), and buf actually points directly to the */
/* data of gaOutL */
I can also post a more complete example of a simple host and CSD
file.

Post by Michael Gogins
If so I think it is a very good idea, but the word 'bus' is misleading.

I am still not sure about the details (including names), so any
suggestions are welcome (more information about the current interface
is included below, quoted from an earlier post).

Post by Michael Gogins
I like the idea of moving FLTK graphs into a plugin for FLTK. I do not
know if this creates a problem for CsoundVST. Probably, if the plugin has
the right kind of event loop and thread locking, it should be possible to
transfer the event loop to the plugin when CsoundVST is running, and get
it back when Csound is finished, or something. As long as there is a
Csound yield API this should all be doable.

And how about these functions ? Is it important to keep them ?
PUBLIC void csoundSetFLTKThreadLocking(CSOUND *, int isLocking);
PUBLIC int csoundGetFLTKThreadLocking(CSOUND *);
-------------------------------------------------------------------------

As I already mentioned, I am not sure about the channel metadata,
so it may be changed significantly if requested, or it may even be
removed completely. Generally, the information on input/output direction,
unknown/integer/linear/exponential control type, default, minimum,
and maximum control value are only hints that can be used by the host
application to allow the user to connect channels of the bus to some
external ports. For example, knowing that a control channel named
"FilterFrequency" is expected to receive input, has an exponential
scale, should be in the range 100 to 10000 with a default "normal"
setting of 1000, is useful for attaching a knob to that channel.
Basically, there are two types of metadata: the input/output bitmask
is always present, and if a new query of the channel is made with an
asig chnget "foo" ; creates channel, with input bit set
chnset asig, "foo" ; this will set output too, so mode is now 3
The other type of metadata is optional and is for control channels only,
it provides information on the expected range of the control data; the
parameters included are "type" (unknown, integer, linear, exponential),
"default value", "minimum value", and "maximum value".
All these additional parameters are only relevant if you intend to use
this system for implementing communication between the orchestra and
the host application (as an alternative to invalue/outvalue).
If all you need is "named ZAK", accessed only from the orchestra, then
using only chnset and chnget should be fine, without caring about the
rest of the opcodes or the various special parameters (they do make
the channel lookup somewhat slower, though, so that may be one reason
to remove all support for metadata).

Post by Michael Gogins
As for chn_k, I'm a little confused on itype for that opcode, as it
would seem to me by its nature it's going to be a control signal.

itype for chn_k selects an optional "sub-type" for the control channel,
which can also be changed by a later chn_k call.
itype = 0
generic control channel (idflt, imin, and imax are ignored),
with no information on the range of the data
itype = 1
the channel data is expected to be limited to integer values
itype = 2
the channel data is expected to have a linear scale
itype = 3
the channel data is expected to have an exponential scale
; name mode type default min max
gkamp chnexport "Amplitude", 1, 3, 0.5, 0.001, 1
gkampDB chnexport "Amplitude_DB", 1, 2, -6, -60, 0
gkfreq chnexport "Frequency", 1, 3, 440, 20, 20000
gknote chnexport "Note_Number", 1, 1, 60, 1, 127
Note again that all the parameters are only hints, and have no effect
at all on the actual use of the channel.

Post by Michael Gogins

There is an implementation of the opcodes and API functions in the CVS
sources now, so you can try it and suggest changes (probably many are
needed, but at least there is something to get started with).
The "casting" of types by opcodes, as requested by Steven Yi, is not
(yet) supported, however, it is possible to create channels from actual
orchestra variables, making it easier and more efficient to implement
communication between the orchestra and the host application.
Also, there is some "metadata" such as input/output direction, and
optional parameters for control channels (integer/linear/exponential
type, default, minimum, and maximum value); these probably need to be
changed too, or may be removed if not found to be useful.
OPCODES
ival chnget Sname
kval chnget Sname
aval chnget Sname
Sval chnget Sname
Read value from a channel (created if does not exist yet, with an initial
value of zero; otherwise, it must be of a compatible type).
chnset ival, Sname
chnset kval, Sname
chnset aval, Sname
chnset Sval, Sname
Write to a channel (created if does not exist yet; otherwise, it must be
of a compatible type).
chn_k Sname, imode[, itype, idflt, imin, imax]
Declare control channel. imode is a sum of 1 for input and 2 for output.
For more information on input/output mode and the optional arguments, see
the API function below.
chn_a Sname, imode
chn_S Sname, imode
Declare audio or string channel.
gival chnexport Sname, imode[, itype, idflt, imin, imax]
gkval chnexport Sname, imode[, itype, idflt, imin, imax]
gaval chnexport Sname, imode
gSval chnexport Sname, imode
Export a global variable as a channel of the bus that should not exist
before calling the opcode. Allows the host application to read or write
orchestra variables directly.
The parameters are the same as in the case of chn_k/chn_a/chn_S.
itype, imode, ictltype, idflt, imin, imax chnparams
Query parameters of a channel (if it does not exist, all returned values
channel data type (1: control, 2: audio, 3: string)
sum of 1 for input and 2 for output
special parameters for control channel only; if not available, all are
set to zero
API FUNCTIONS
/**
* Stores a pointer to the specified channel of the bus in *p,
* creating the channel first if it does not exist yet.
* 'type' must be the bitwise OR of exactly one of the following values,
* CSOUND_CONTROL_CHANNEL
* control data (one MYFLT value)
* CSOUND_AUDIO_CHANNEL
* audio data (csoundGetKsmps(csound) MYFLT values)
* CSOUND_STRING_CHANNEL
* string data (MYFLT values with enough space to store
* csoundGetStrVarMaxLen(csound) characters, including the
* NULL character at the end of the string)
* CSOUND_INPUT_CHANNEL
* CSOUND_OUTPUT_CHANNEL
* If the channel already exists, it must match the data type (control,
* audio, or string), however, the input/output bits are OR'd with the
* new value. Note that audio and string channels can only be created
* after calling csoundCompile(), because the storage size is not known
* until then.
* Return value is zero on success, or a negative error code,
* CSOUND_MEMORY there is not enough memory for allocating the channel
* CSOUND_ERROR the specified name or type is invalid
* or, if a channel with the same name but incompatible type already exists,
* the type of the existing channel. In the case of any non-zero return
* value, *p is set to NULL.
* Note: to find out the type of a channel without actually creating or
* changing it, set 'type' to zero, so that the return value will be either
* the type of the channel, or CSOUND_ERROR if it does not exist.
*/
PUBLIC int csoundGetChannelPtr(CSOUND *,
MYFLT **p, const char *name, int type);
/**
* Returns a list of allocated channels, storing a pointer to an array
* of channel names in *names, and a pointer to an array of channel types
* in *types. (*types)[n] corresponds to (*names)[n], and has the same
* format as the 'type' parameter of csoundGetChannelPtr().
* The return value is the number of channels, which may be zero if there
* are none, or CSOUND_MEMORY if there is not enough memory for allocating
* the lists. In the case of no channels or an error, *names and *types are
* set to NULL.
* Note: the caller is responsible for freeing the lists returned in *names
* and *types with free(), however, the actual channel names should not be
* changed or freed. Also, the name pointers may become invalid after calling
* csoundReset().
*/
PUBLIC int csoundListChannels(CSOUND *, char ***names, int **types);
/**
* type: must be one of CSOUND_CONTROL_CHANNEL_INT,
* CSOUND_CONTROL_CHANNEL_LIN, or
CSOUND_CONTROL_CHANNEL_EXP for
* integer, linear, or exponential channel data, respectively,
* or zero to delete any previously assigned parameter information
* dflt: the control value that is assumed to be the default, should be
* greater than or equal to 'min', and less than or equal to 'max'
* min: the minimum value expected; if the control type is exponential,
* it must be non-zero
* max: the maximum value expected, should be greater than 'min';
* if the control type is exponential, it must be non-zero and
* match the sign of 'min'
* CSOUND_ERROR: the channel does not exist, is not a control channel,
* or the specified parameters are invalid
* CSOUND_MEMORY: could not allocate memory
*/
PUBLIC int csoundSetControlChannelParams(CSOUND *, const char *name,
int type, MYFLT dflt,
MYFLT min, MYFLT max);
/**
* Returns special parameters (assuming there are any) of a control channel,
* previously set with csoundSetControlChannelParams().
* If the channel exists, is a control channel, and has the special parameters
* assigned, then the default, minimum, and maximum value is stored in *dflt,
* *min, and *max, respectively, and a positive value that is one of
* CSOUND_CONTROL_CHANNEL_INT, CSOUND_CONTROL_CHANNEL_LIN, and
* CSOUND_CONTROL_CHANNEL_EXP is returned.
* In any other case, *dflt, *min, and *max are not changed, and the return
* value is zero if the channel exists, is a control channel, but has no
* special parameters set; otherwise, a negative error code is returned.
*/
PUBLIC int csoundGetControlChannelParams(CSOUND *, const char *name,
MYFLT *dflt, MYFLT *min, MYFLT *max);

Iain Duncan

2005-09-25 20:57:14 UTC

Permalink

For what it's worth, I am totally in agreement with Michael on the
python incorporation. I think it increases the scope of csound
usefullness for unusual live or real time situations immensly.

Iain

Post by Michael Gogins
To start with, I really, really appreciate all the excellent work you
have put into Csound.
The bus interface permits external software (API clients) to directly
get and set Csound variables -- is that correct? If so I think it is a
very good idea, but the word 'bus' is misleading.
I suggest replacing rand() with csound_rand() -- either Whittle's code
or the Mersenne Twister (I would prefer the latter since I think it is
more random and I think we can afford the small additional overhead).
Perhaps it could be an option to the opcode, which implementation to use.
I am not trying to get CsoundVST as a whole into libcsound, precisely
for the reason you cite -- increased dependencies. I am only trying to
get a Python wrapping for libcsound into libcsound. No boost or FLTK!
The Python dependency already exists in the build system for those who
build Csound, and for those who not have Python, the interface code will
just sit there and do nothing. It should not prevent libcsound from
either linking or running on systems that do not have Python.
The reason for this is that my compositional productivity with Python
has been significantly higher coding in Python than in any other
language I've used, and I'd like to see this benefit made more
accessible for other csounders. Plus, Python has a truly rich set of
libraries that would add significantly to what can be done with Csound.
If this were done, I might be able to factor stuff out of CsoundVST so
it would be easier to use it as the default FLTK user interface for
Csound (i.e., no "Silence" classes or boost). My algo-comp stuff would
go into a separate, independent Python extension.
I know people might say you can code scores in Python and just exec
Csound, but that's what I used to do, and the way I work now is a lot
better. Keeping track of one file per piece instead of 2 or 3 files ends
up making a lot of difference in terms of production efficiency.
After thinking about plugin metadata, I think it is a bad idea. It is
better to define a standard directory structure and format, consistent
with the existing excellent manual, for more extensive plugin
documentation. It should be the case that when users install plugins,
they can rebuild the manual and the plugin pages automatically get built
into the manual. If that's too hard, then a standard HTML format for
plugin pages should be defined, consistent with the manual. Some
Javascript should enable a kind of integration with the existing manual.
I like the idea of moving FLTK graphs into a plugin for FLTK. I do not
know if this creates a problem for CsoundVST. Probably, if the plugin
has the right kind of event loop and thread locking, it should be
possible to transfer the event loop to the plugin when CsoundVST is
running, and get it back when Csound is finished, or something. As long
as there is a Csound yield API this should all be doable.
Regards,
Mike
Sent: Sunday, September 25, 2005 6:35 AM
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Post by Istvan Varga

Post by Michael Gogins
Istvan, what do you think needs to be done before a release?

Post by Michael Gogins
Do all the utilities run in 32 and 64 bits? I only care if they
run inside Csound, I don't care about the standalone invocation.

Post by Michael Gogins
Is there anything we can do to get FLTK working simultaneously
for Ftable display and for FLTK widgets?

I would prefer moving the FLTK table displays out of the engine
as well, leaving only the old ASCII and PostScript code as built-in.
It may be possible to integrate the display and widget code into
a single plugin that uses the API calls to register all the MakeGraph
and other functions, and having all FLTK stuff in one place again
might allow for easier fixing of the problems related to using
displays and widgets at the same time.
Also, not having FLTK displays in the main library means no
dependencies on FLTK or C++ at all, and the functions related to
FLTK locking could be removed from the API as well. I do not know,
though, if this is a problem for CsoundVST that also uses FLTK.
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

2005-10-01 10:44:26 UTC

Permalink

Post by Michael Gogins
I suggest replacing rand() with csound_rand() -- either Whittle's code
or the Mersenne Twister (I would prefer the latter since I think it is
more random and I think we can afford the small additional overhead).
Perhaps it could be an option to the opcode, which implementation to use.

I have added these new API functions:

/**
* Simple linear congruential random number generator:
* (*seedVal) = (*seedVal) * 742938285 % 2147483647
* the initial value of *seedVal must be in the range 1 to 2147483646.
* Returns the next number from the pseudo-random sequence,
* in the range 1 to 2147483646.
*/
PUBLIC int csoundRand31(int *seedVal);

/**
* Initialise Mersenne Twister (MT19937) random number generator,
* using 'keyLength' unsigned 32 bit values from 'initKey' as seed.
* If the array is NULL, the length parameter is used for seeding.
*/
PUBLIC void csoundSeedRandMT(CsoundRandMTState *p,
const uint32_t *initKey, uint32_t keyLength);

/**
* Returns next random number from MT19937 generator.
* The PRNG must be initialised first by calling csoundSeedRandMT().
*/
PUBLIC uint32_t csoundRandMT(CsoundRandMTState *p);

the CsoundRandMTState type is:

typedef struct CsoundRandMTState_ {
int mti;
uint32_t mt[624];
} CsoundRandMTState;

All uses of rand() have been removed. The following opcodes now use a
global (per instance of Csound) Mersenne Twister, and can be seeded
with the 'seed' opcode:

unirand, linrand, trirand, exprand, bexprnd, cauchy, pcauchy,
poisson, gauss, weibull, betarand

These opcodes use the 31 bit generator, also global for an instance
of Csound and seedable with the 'seed' opcode:

bbcut, grain, adsynt, phasorbnk, noise, shaker, sndwarp,
sndwarpst, ATSaddnz, ATSsinnoi, adsynt2

also the various physical model opcodes (marimba, cabasa,
sekere, singwave, etc. - there are quite a few)

In addition, the widget opcodes that allow for randomly changing
the style of displayed widgets now use a 31 bit PRNG that is always
seeded from the current time.

The 31 bit generator may be changed to use a different multiplier or
even a different algorithm if requested, and also the selection of
PRNG in the various opcodes can be changed. In fact, the MT could be
used in all, I only limited it to the "x-class" random opcodes to
make those more predictable (that is, for example to prevent the output
of unirand from changing if a grain opcode is added elsewhere).
Does anyone suggest changes ?

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Oeyvind Brandtsegg

2005-09-25 19:19:26 UTC

Permalink

Just to phone in my 2 cents.
I, for one, am very interested in getting signals in and out of csound,
for interfacing e.g. with python or some other external process.
Likewise, various apporaches to an internal signal bus, with alternatives for named and numbered channels are highly interesting.
But I haven't found the time to sit down and really read and understand the implications of any of the recent additions and suggestions.
Writing this just to say that there is interest, even if no replies, I simply did not know how to respond, yet.
Oeyvind

Post by Istvan Varga
Currently, one unfinished project is the bus interface, but
it seems from the relative lack of comments that there is not
much interest or demand for it; so, I may consider removing it
for now, keeping only the two opcodes 'chnget' and 'chnset' for
private use by the orchestra, but no API functions or extra
features.

Stéphane Rollandin

2005-09-25 20:49:34 UTC

Permalink

Post by Oeyvind Brandtsegg
Just to phone in my 2 cents.
I, for one, am very interested in getting signals in and out of csound,
for interfacing e.g. with python or some other external process.
Likewise, various apporaches to an internal signal bus, with alternatives for named and numbered channels are highly interesting.
But I haven't found the time to sit down and really read and understand the implications of any of the recent additions and suggestions.
Writing this just to say that there is interest, even if no replies, I simply did not know how to respond, yet.
Oeyvind

same here. I usually drive Csound from Smalltalk and Lisp.
so far I have been using sub-processes launched via shell commands; I
have no idea what to suggest precisely that could help having a better
integration, except that in both langages the Foreign Function Interface
requires a .dll or a .so

could Csound easily be compiled as a dll for use via FFI ?

Stef

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Iain Duncan

2005-09-25 21:00:31 UTC

Permalink

Post by StÃ©phane Rollandin
same here. I usually drive Csound from Smalltalk and Lisp.
so far I have been using sub-processes launched via shell commands; I
have no idea what to suggest precisely that could help having a better
integration, except that in both langages the Foreign Function Interface
requires a .dll or a .so

Same here too. I also like the idea of being able to use both named and
numbered signal paths, even more so I like the idea of being able to mix
the two if that can be made possible. Being able to do:

outsig my_named_channel + koffset, blah, blah

would be very useful ( imaginary opcode, have not had the chance to dig
into these new developments properly ).

Iain

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Michael Gogins

2005-09-25 23:18:43 UTC

Permalink

Yes, csound5 can be compiled as a .dll (Windows) or .so (Linux). The FFI
should be quite easy to add, since the C API for Csound is declared entirely
in csound.h, and entirely as extern "C" cdecl.

Regards,
Mike
----- Original Message -----
From: "Stéphane Rollandin" <***@zogotounga.net>
To: <csound-***@lists.sourceforge.net>
Sent: Sunday, September 25, 2005 4:49 PM
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Post by Oeyvind Brandtsegg
Just to phone in my 2 cents.
I, for one, am very interested in getting signals in and out of csound,
for interfacing e.g. with python or some other external process.
Likewise, various apporaches to an internal signal bus, with alternatives
for named and numbered channels are highly interesting. But I haven't
found the time to sit down and really read and understand the
implications of any of the recent additions and suggestions. Writing this
just to say that there is interest, even if no replies, I simply did not
know how to respond, yet.
Oeyvind

same here. I usually drive Csound from Smalltalk and Lisp.
so far I have been using sub-processes launched via shell commands; I have
no idea what to suggest precisely that could help having a better
integration, except that in both langages the Foreign Function Interface
requires a .dll or a .so
could Csound easily be compiled as a dll for use via FFI ?
Stef
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
https://lists.sourceforge.net/lists/listinfo/csound-devel

Stéphane Rollandin

2005-09-26 05:59:30 UTC

Permalink

Post by Michael Gogins
Yes, csound5 can be compiled as a .dll (Windows) or .so (Linux). The FFI
should be quite easy to add, since the C API for Csound is declared
entirely in csound.h, and entirely as extern "C" cdecl.

ok, thanks.

Stef

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Iain Duncan

2005-09-25 20:55:46 UTC

Permalink

Post by Istvan Varga
I do not really have many ideas at this time, and that is one
of the reasons why I keep asking if anyone else does.
Currently, one unfinished project is the bus interface, but
it seems from the relative lack of comments that there is not
much interest or demand for it; so, I may consider removing it
for now, keeping only the two opcodes 'chnget' and 'chnset' for
private use by the orchestra, but no API functions or extra
features.

As a user, I think that is a good plan. I would prefer to wait for a
more complete bus interface that doesn't get rushed out the door.

Post by Istvan Varga
Another issue is replacing the use of rand() in various opcodes
with an API function that generates random numbers in a more
portable way, and without the problems associated with rand()
when used from multiple instances at the same time. This is not
really important, but it changes the output of the opcodes, so
is better done before the release.

That sounds great too. Dealing with windows/linux rand incompatibilities
is quite annoying to relatively new programmers so good random
generators within csound would be very handy.

Post by Istvan Varga
It may also be worth to clean up the use of temporary files,
but this is a low priority issue too.

I have a question on this, will csound5 gracefully handle no disk for
temp files? Can it create them in memory? I am just thinking about use
on live CDs. Csound5 will be included on the new Dyne:bolic II and
Pure:Dyne live CDs.

Post by Istvan Varga
What is definitely to be done before a release is finishing
the API so that all incompatible changes (even if something
minor like renaming functions, changing the layout of structures,
etc.) are done now. As there are no comments on this issue,
it is tempting to leave everything as it is, but I am afraid
that people will start to complain when the interface is already
considered frozen and thus it is too late.

I agree there too. The api moves alot, would be great to have that
stabilized as well as possible. When that happens, I would be happy to
contribute my fairly simple api host example programs for the examples
included with the release.

Thanks for listening,
Iain

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

David Akbari

2005-09-26 17:36:11 UTC

Permalink

Hi List,

Post by Istvan Varga

Michael Gogins

2005-09-26 19:44:38 UTC

Permalink

My suggestion would preserve the "separateness between the small, efficient, and elegant CsoundLib and
the Python interpreter" that you note. The CsoundLib would remain small and efficient. My suggestion also would not replace or change the Python opcodes or pyext.

Regards,
Mike

-----Original Message-----
From: David Akbari <***@gmail.com>
Sent: Sep 26, 2005 1:36 PM
To: csound-***@lists.sourceforge.net
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Hi List,

Post by Istvan Varga

Catching up on emails today, I feel that the response to this
suggestion is VERY important and deserves reiteration.

For example for using Python, I prefer using Thomas Grill's py/pyext
for Pd in conjunction with csoundapi~ also in Pd.

http://grrrr.org/ext/

Of course this is by no means a "substitute" for CsoundVST, but allows
a similar and possibly comparable function while maintaining a
separateness between the small, efficient, and elegant CsoundLib and
the Python interpreter.

-David

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php