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

Regards,
Mike

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

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

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

Victor

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





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