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

Recently I was looking through ugnorman.c which contains the sources 
for the ATS opcodes but is only implemented as a plugin module for 
Csound4 (at present). I've been trying to convert the API functions 
used in ugnorman.c to use Csound5's API but so far unsuccessful. Things 
like "stderr" and "initerr" are what is most confusing; mostly error 
handling functions in Csound4's API that I'm uncertain of what their 
equivalencies for Csound5 are (although I think the initerror one is 
csound->Die() ??)

It would seem that these opcodes (ATS) would be a worthwhile addition 
to Csound5's already extensive library of spectral / streaming / etc 
opcodes and could provide even more reasons to use Csound as opposed to 
another software synthesizer (eg SuperCollider). Other than that, it 
would seem that the API is much cleaner / easily accessible as it is 
implemented today than even just one month ago.

Performance on Mac OSX is adequate, albeit slower than Csound5 on x86 
processors - as the average Mac processor can be as little as 1/3 as 
fast as a typical x86 processor. Mostly everyone I've talked to that 
desires to use Csound5 on the Mac is talking about the need for an 
easily accessible frontend (like MacCsound) but with Csound5's crucial 
updates (of course there is also Blue for this purpose) -- the typical 
professional studio musician that would use Csound on the Mac is also a 
person who loathes using the commandline and prefers to stick to pretty 
GUI's like Logic, for example. Personally I've found Victor's 
csoundapi~ for Pd to be a wonderful compromise.

Since I've began using Csound5 on OSX, I have still yet to be able to 
compile CsoundVST (can SWIG and Boost be built on OSX?) due to library 
dependencies that reach beyond the scope of the canonical sources as 
well as extension modules (like Loris and the python opcodes) which 
rely on CsoundVST (or the Boost/SWIG headers). I have all the required 
external sources in the correct places, and the SConstruct flags 
reflect the intent to compile these modules accordingly, however still 
no go. Has anyone been successful yet in this pursuit? I'm dying to 
hear about someone doing this - it would certainly be a welcome 
inspiration.

Anyway, Istvan periodically mentions "to be at or better than the 
status of Csound4" to be a requisite for the release of Csound5 and I 
personally feel like the present status of Csound5 has more than 
surpassed this (on Windows, Linux, and Mac OSX at least - I don't have 
access to a computer that runs Irix or Solaris).

All things considered, it almost feels like Csound5 was released a 
month or more ago. The only reason I use anything related to Csound4 
anymore is solely for MacCsound.

$0.02 well spent,
-David

On Aug 25, 2005, at 8:36 AM, Istvan Varga wrote:

> 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 ?
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Akbari wrote:

> Recently I was looking through ugnorman.c which contains the sources for 
> the ATS opcodes but is only implemented as a plugin module for Csound4 
> (at present). I've been trying to convert the API functions used in 
> ugnorman.c to use Csound5's API but so far unsuccessful. Things like 
> "stderr" and "initerr" are what is most confusing; mostly error handling 
> functions in Csound4's API that I'm uncertain of what their 
> equivalencies for Csound5 are (although I think the initerror one is 
> csound->Die() ??)

Here are some functions commonly used in Csound 4 opcodes for printing
messages, and their Csound 5 equivalents:

printf("...");               csound->Message(csound, "...");
fprintf(stderr, "...\n");    csound->Message(csound, "...\n");
                           or csound->ErrorMsg(csound, "...");
err_printf("...\n");         csound->Message(csound, "...\n");
                           or csound->ErrorMsg(csound, "...");
warning("...");              csound->Warning(csound, "...");
initerror("...");            csound->InitError(csound, "...");
perferror("...");            csound->PerfError(csound, "...");
die("...");                  csound->Die(csound, "...");

Note that all Csound 5 functions allow for using a printf-style format
and argument list, making the previously common practice of writing the
message to a small buffer first with sprintf() and then printing the
buffer unnecessary. Most functions append a newline character to the
output (exceptions include Message, MessageS, and MessageV).
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Akbari wrote:

> Recently I was looking through ugnorman.c which contains the sources for 
> the ATS opcodes but is only implemented as a plugin module for Csound4 
> (at present). I've been trying to convert the API functions used in 
> ugnorman.c to use Csound5's API but so far unsuccessful. Things like 
> "stderr" and "initerr" are what is most confusing; mostly error handling 
> functions in Csound4's API that I'm uncertain of what their 
> equivalencies for Csound5 are (although I think the initerror one is 
> csound->Die() ??)
> 
> It would seem that these opcodes (ATS) would be a worthwhile addition to 
> Csound5's already extensive library of spectral / streaming / etc 
> opcodes and could provide even more reasons to use Csound as opposed to 
> another software synthesizer (eg SuperCollider). Other than that, it 
> would seem that the API is much cleaner / easily accessible as it is 
> implemented today than even just one month ago.

I may try porting these opcodes if you send the original (Csound 4)
source code.

> Performance on Mac OSX is adequate, albeit slower than Csound5 on x86 
> processors - as the average Mac processor can be as little as 1/3 as 
> fast as a typical x86 processor. Mostly everyone I've talked to that 
> desires to use Csound5 on the Mac is talking about the need for an 
> easily accessible frontend (like MacCsound) but with Csound5's crucial 
> updates (of course there is also Blue for this purpose) -- the typical 
> professional studio musician that would use Csound on the Mac is also a 
> person who loathes using the commandline and prefers to stick to pretty 
> GUI's like Logic, for example. Personally I've found Victor's csoundapi~ 
> for Pd to be a wonderful compromise.
> 
> Since I've began using Csound5 on OSX, I have still yet to be able to 
> compile CsoundVST (can SWIG and Boost be built on OSX?) due to library 
> dependencies that reach beyond the scope of the canonical sources as 
> well as extension modules (like Loris and the python opcodes) which rely 
> on CsoundVST (or the Boost/SWIG headers). I have all the required 
> external sources in the correct places, and the SConstruct flags reflect 
> the intent to compile these modules accordingly, however still no go. 
> Has anyone been successful yet in this pursuit? I'm dying to hear about 
> someone doing this - it would certainly be a welcome inspiration.

Many of these issues are unfortunately the result of Mac developers
contributing nothing to Csound 5 development, while all the currently
active main developers of Csound 5 and CsoundVST use either Linux or Windows.
The only significant OS X specific addition in the last few months was the
new CoreAudio plugin by Victor Lazzarini.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Hi Istvan,

On Aug 27, 2005, at 10:38 AM, Istvan Varga wrote:

> I may try porting these opcodes if you send the original (Csound 4)
> source code.
>

The original source code for the ATS opcodes are called "ugnorman" 
.c/.h respectively. I put them on cSounds.com and they can be found at 
the following URLs (as opposed to posting a lot of text to a mailing 
list).

http://www.csounds.com/resources/ugnorman.h
http://www.csounds.com/resources/ugnorman.c

I have been able to make some minor progress from your last email that 
was detailing various Csound4 functions and their Csound5 equivalents 
(very helpful!!) but what I still lack in both Csound5 and Csound4 is a 
way to tie in things like "strsmax", "strsets", "sstrcod", etc with the 
GLOBALS structure (Csound4) and CSOUND structure (Csound5).

> Many of these issues are unfortunately the result of Mac developers
> contributing nothing to Csound 5 development,

In our unique community, when an individual can be both a programmer 
and a musician simultaneously, it's no surprise (albeit unfortunate) 
that things (or gigs) can come up and get in the way of development.

>  while all the currently
> active main developers of Csound 5 and CsoundVST use either Linux or 
> Windows.
> The only significant OS X specific addition in the last few months was 
> the
> new CoreAudio plugin by Victor Lazzarini.

You are of course right about the status of Csound5 development on the 
Macintosh platform; but it's thanks to individuals like Victor 
Lazzarini (his "Extensions to Csound" paper) and Anthony Kozar that the 
information necessary to get other individuals into contributing to 
Csound that were previously unable to do so is now increasingly more 
possible than it was previously.

Hopefully in time, individuals such as myself will be able to 
contribute something to active Csound development on the Macintosh... 
however IMHO, Mac OS 10.4 Tiger's "new features" are at best 
unappealing and I don't plan on updating from 10.3.9 in the near 
future. The only downside is no GCC 4. =\


-David

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Akbari wrote:

> The original source code for the ATS opcodes are called "ugnorman" .c/.h 
> respectively. I put them on cSounds.com and they can be found at the 
> following URLs (as opposed to posting a lot of text to a mailing list).
> 
> http://www.csounds.com/resources/ugnorman.h
> http://www.csounds.com/resources/ugnorman.c

The opcodes are now in Csound 5 CVS, although were not tested yet.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

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

At 13:36 25/08/2005, you wrote:
>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
>Csound-devel@lists.sourceforge.net
>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-devel@lists.sourceforge.net

Victor Lazzarini wrote:

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

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

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

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.

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

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

> From simple things, such as what holds the sampling rate,

CSOUND.esr

> vectorsize,

CSOUND.ksmps

 > normalisation level, etc,

CSOUND.e0dbfs

> to what functions to use to do a FFT,

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

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

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

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

At 12:27 29/08/2005, you wrote:
>Victor Lazzarini wrote:
>
>>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.
>
>>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.
>
>>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.
>
>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.
>
>>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.
>
>>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.
>
>> From simple things, such as what holds the sampling rate,
>
>CSOUND.esr
>
>>vectorsize,
>
>CSOUND.ksmps
>
> > normalisation level, etc,
>
>CSOUND.e0dbfs
>
>>to what functions to use to do a FFT,
>
>All functions in CSOUND that have "FFT" in the name.
>Documented in H/fftlib.h.
>
>>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.
>
>>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
>Csound-devel@lists.sourceforge.net
>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-devel@lists.sourceforge.net

Victor Lazzarini wrote:

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

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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
anthonykozar@sbcglobal.net
http://akozar.spymac.net/


Istvan Varga wrote on 8/29/05 8:11 AM:

>> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The opcodes are already in the Csound 5 CVS sources, but I could not
test them yet. Is there a manual for the ATS opcodes ? Also, an utility
to create ATS files would be useful.

David Akbari wrote:

> The original source code for the ATS opcodes are called "ugnorman" .c/.h 
> respectively. I put them on cSounds.com and they can be found at the 
> following URLs (as opposed to posting a lot of text to a mailing list).
> 
> http://www.csounds.com/resources/ugnorman.h
> http://www.csounds.com/resources/ugnorman.c
> 
> I have been able to make some minor progress from your last email that 
> was detailing various Csound4 functions and their Csound5 equivalents 
> (very helpful!!) but what I still lack in both Csound5 and Csound4 is a 
> way to tie in things like "strsmax", "strsets", "sstrcod", etc with the 
> GLOBALS structure (Csound4) and CSOUND structure (Csound5).
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

The original ATS opcode package is here:

http://sourceforge.net/projects/atsa
SourceForge.net: Project Info - ATS

Documentation is in the ats-csound download and is already in "Csound
format".  The ATS library (not the opcode lib) includes tools for analysis.

The license for ATS and the ATS opcodes should be checked for compatibility
with Csound!

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

Istvan Varga wrote on 8/29/05 10:00 AM:

> The opcodes are already in the Csound 5 CVS sources, but I could not
> test them yet. Is there a manual for the ATS opcodes ? Also, an utility
> to create ATS files would be useful.

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Anthony Kozar wrote:

> The license for ATS and the ATS opcodes should be checked for compatibility
> with Csound!

What is the license ? If it is incompatible with the LGPL, I will remove
the opcodes from Csound 5 CVS.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

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

Victor

At 14:50 29/08/2005, you wrote:
>If I can get the current Csound 5 CVS to compile on OS X, I will begin to
>look into these issues.

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

Anthony Kozar wrote:

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

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

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

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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

At 16:28 29/08/2005, you wrote:
>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.

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

Victor Lazzarini wrote:

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

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

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

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

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

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

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

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

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



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

Well, looking myself, I can find no license info in the ats-csound
distribution.  And it appears to be based on Richard Karpen's pvadd code
from Csound and (I assume) the ATS library.  The ATS library itself
effectively has a carte blanche to do anything:

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

So, I would guess that there is no trouble incorporating it into Csound 5.
But emailing Alex Norman to be sure probably would not hurt :)

alexnorman AT users.sourceforge.net

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

Istvan Varga wrote on 8/29/05 10:50 AM:

> Anthony Kozar wrote:
> 
>> The license for ATS and the ATS opcodes should be checked for compatibility
>> with Csound!
> 
> What is the license ? If it is incompatible with the LGPL, I will remove
> the opcodes from Csound 5 CVS.

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

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

Thanks

Victor

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

Steven Yi wrote:

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

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


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

Anthony Kozar wrote:

> So, I would guess that there is no trouble incorporating it into Csound 5.

OK, then I do not delete the opcodes for now. Is it also possible to port
the utility needed for creating ATS files to Csound, so that it can be
used like hetro or pvanal ?
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

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

Anyway,

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

It's currently failing with

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

and a previous

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

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


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


              Graham






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

Graham Breed wrote:

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

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

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

with

#if defined(LINUX)

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


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

Steven Yi wrote:

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

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


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

Graham Breed wrote:

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


-David



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

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

Victor

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

Victor Lazzarini wrote:

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

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

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

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


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

Istvan Varga wrote:

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

It compiles fine, and then this happens:

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


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


                    Graham



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

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

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

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

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

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


                   Graham


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

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

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

Hi Graham,

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

The way you can check is by doing simply a

./csound -z

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

To set an environment variable in OSX you do

(bash shell - the default shell)

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

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

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

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

Hope this helps!


-David



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

David Akbari wrote:

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

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

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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
anthonykozar@sbcglobal.net
http://akozar.spymac.net/


Istvan Varga wrote on 8/30/05 8:49 AM:

> Victor Lazzarini wrote:

>> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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


At 15:15 31/08/2005, you wrote:
>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
>anthonykozar@sbcglobal.net
>http://akozar.spymac.net/
>
>
>Istvan Varga wrote on 8/30/05 8:49 AM:
>
> > Victor Lazzarini wrote:
>
> >> 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
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>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-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:
> 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?

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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Can this wait until I am in computer contatc wih the world?


On Thu, 25 Aug 2005, Istvan Varga wrote:

> 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 ?
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 
> 
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

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

On Thu, 2005-08-25 at 07:36, Istvan Varga wrote:
> 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:
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-devel@lists.sourceforge.net

Andres Cabrera wrote on 9/22/05 11:31 PM:

> 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.
[...]
> 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.

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

Also, from a while back:

Istvan Varga wrote on 9/9/05 5:00 AM:

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

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

>> - 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

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

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

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.

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote on 9/23/05 5:07 AM:

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Anthony Kozar wrote:
>
>> 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:


	
		
			YourOpcodeName
			outtype	YourOpcodeName	inarg1, [ ioptarg1 ]
		
[ ... more opcode data here ]
	
[ ... more groups here ]


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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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


On Fri, 2005-09-23 at 12:15, Istvan Varga wrote:
> Anthony Kozar wrote:
> 
> > 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
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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

Istvan Varga wrote:
> Anthony Kozar wrote:
> 
>> 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
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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

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




Istvan Varga wrote:

> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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?
ares oscil xamp, xcps, ifn [,
iphs]
Maybe a new variable called something like CSDOCDIR would be necessary?

Cheers,
Andrés

On Fri, 2005-09-23 at 12:47, Steven Yi wrote:
> 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
> 
> 
> On 9/23/05, Anthony Kozar  wrote:
> > Istvan Varga wrote on 9/23/05 5:07 AM:
> >
> > > 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
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@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
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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



On Sep 24, 2005, at 9:54 AM, Richard Dobson wrote:

> 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
>
>
>
>
> Istvan Varga wrote:
>
>
>> 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
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> 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
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

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/


Andres Cabrera wrote on 9/24/05 1:27 PM:

> 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?
> ares oscil xamp, xcps, ifn [,
> iphs]



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