I might want to include csoundCore.h. At present, I guess this means I would have to ONLY include that and not csound.h, is that correct?

Regards,
Mike

-----Original Message-----
From: Istvan Varga 
Sent: Aug 17, 2005 10:30 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] csound.h

Michael Gogins wrote:

> I suggest a compromise whereby there are 2 header files. The high
> level API would declare CSOUND as opaque and the low level API would
> declare all details of Csound internals.

A completely opaque CSOUND, while preferred for hosts, is not suitable
for plugins, because dynamically loaded libraries need access to at
least the function pointers, but preferably also to some variables.
Of course, one could just drop support for a static Csound library, and
then the plugins may simply link against the DLL file, but a plugin
still runs at a lower level (as a subroutine of csoundPreCompile,
csoundCompile, csoundPerformKsmps (and related), or csoundRunUtility)
than a host application.

> The compromise is that it should be possible to include either, or
> both, of these headers from any project.

I assume you do not want to include the low level csoundCore.h
interface in your project that is not part of the Csound library ?

> The vital point is that it is not wise to decide in advance what
> users of the API need to see or call.

Users of the API generally should not see anything that is either
not expected to work correctly if not run in the right context
(examples include many of the function pointers in CSOUND, intended
for use in plugin libraries only), or is subject to frequent
incompatible changes.

> For example, I think if I were to write a composition environment in
> C using the Csound API, my program would need to reference all parts
> of the API to enumerate opcodes, create function tables, manage VST
> plugins, create lists of notes using cscore facilities, allocate
> memory, create threads, intercept opcode function calls, etc., etc.

Then those facilities can be added to the API, with a well defined and
stable interface. However, just using some random low level internals
can be dangerous, even if it may often appear to work.



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

Michael Gogins wrote:

> I might want to include csoundCore.h.
 > At present, I guess this means I would have to ONLY include
 > that and not csound.h, is that correct?

No, csoundCore.h should not be included by anything that is not
part of the engine (that is, files in Engine, OOps, Top, and InOut,
not including any plugins). If you want to have the functionality
of both csound.h and csdl.h, it is currently possible to include
these two headers from the same file (csound.h first, and then
csdl.h); beware, however, that many of the functions that can be
found in the CSOUND structure, but not in csound.h or files included
by csound.h may not always work correctly when called directly by a
host application. Possible problems include uses of ids, pds, curip,
or other variables in CSOUND that are only valid while the various
"perform" functions are being called, and longjmp.


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

Just my two cents:

A host application may definitely want to also act as a "plugin" --
registering new opcodes as well as audio and Midi callbacks.  Maybe that is
already possible with csound.h (haven't looked), but it should be possible
to include both csound.h and csdl.h in the same file.

I like the separation, by the way, if it can be done cleanly.  One thing
that really needs to be done (if it hasn't been already) is to document when
each function or variable in the API is valid to use.

(BTW, giving up static linking for the Csound library should not be an
option ...)

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

Istvan Varga wrote on 8/17/05 11:46 AM:

> Michael Gogins wrote:
> 
>> I might want to include csoundCore.h.
>> At present, I guess this means I would have to ONLY include
>> that and not csound.h, is that correct?
> 
> No, csoundCore.h should not be included by anything that is not
> part of the engine (that is, files in Engine, OOps, Top, and InOut,
> not including any plugins). If you want to have the functionality
> of both csound.h and csdl.h, it is currently possible to include
> these two headers from the same file (csound.h first, and then
> csdl.h);
[...]



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

> A host application may definitely want to also act as a "plugin" --
> registering new opcodes as well as audio and Midi callbacks.  Maybe that is
> already possible with csound.h (haven't looked), but it should be possible
> to include both csound.h and csdl.h in the same file.

It is possible (although not recommended) to include both csound.h and csdl.h
at the same time, as long as it is done in this order. However, you can also
just put the implementation of the opcode, audio or MIDI driver, or whatever
else that is normally implemented as a plugin into a separate file which
includes csdl.h.
You can already register audio and MIDI drivers from a host application,
but it should be done between calling csoundPreCompile and csoundCompile,
and you need to pass the '-+rtaudio=null' and '-+rtmidi=null' command
line options to csoundCompile to prevent any plugins from overriding your
callbacks.
csoundAppendOpcode() can also be called from hosts, however, it currently
does not work if used this way.


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

> A host application may definitely want to also act as a "plugin" --
> registering new opcodes

This is now also possible, using csoundAppendOpcode between csoundPreCompile
and csoundCompile. Opcodes can be listed with csoundNewOpcodeList (now works,
but should be called after loading an orchestra with csoundCompile).


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