csound.h

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

csound.h

Steven Yi
Hi All,

Regarding CS5 and a release, I think one thing that should be
addressed is the csound.h file.  I know with Matt's MacCsound, all
things necessary for either a plugin or host is contained in csound.h.
 I think this would be ideal.  Currently there's a split between
csound.h and csoundCore.h.  Any thoughts?

Also, at the moment with the current SConstruct files, all .h files
seem to be installed into /usr/local/include/csound which seems a bit
overkill.  I think it'd be great if we could start putting together a
separate opcode SDK package that has a very simple plugin opcode with
Makefile--which I think is plenty enough for an opcode plugin--that
can compile using just what will be installed, to help encourse
external opcode building.

Thanks,
steven


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

Re: csound.h

Istvan Varga
Steven Yi wrote:

> Regarding CS5 and a release, I think one thing that should be
> addressed is the csound.h file.  I know with Matt's MacCsound, all
> things necessary for either a plugin or host is contained in csound.h.
>  I think this would be ideal.  Currently there's a split between
> csound.h and csoundCore.h.  Any thoughts?

The separate files are there to provide access to the interfaces needed
(but not more) for a particular type of application (hosts, plugins, and
internals), while hiding as much of anything else as possible to reduce
namespace pollution and prevent host applications and plugins from using
"private" internal types and functions that change frequently in an
incompatible way. Also, many of the API functions only make sense (and in
fact only work correctly) in plugins, but not in host applications;
examples include those that take a pointer to an opcode data structure
as argument, or those that may possibly call longjmp.

So, there are these header files, of which you should always include
exactly one:

csound.h:     for host applications

This interface is the most limited, it allows access only to the standard
API functions for creating a Csound instance, compiling, performing, registering
a message callback, etc. It also declares CSOUND as an incomplete "opaque"
type of which the contents cannot be accessed.
Of course, not being able to use any internals also means not being broken
by changes to the various structures, and there is significantly less amount
of namespace pollution from all the macros and typedefs in the other header
files.

csdl.h:       for plugins

This interface makes it possible to use function pointers as well as a limited
set of "public" data in the CSOUND structure, and also all the structures and
macros that are expected to be used by a plugin library.
It does not, however, declare function prototypes, and some internal data types
are still hidden.

csoundCore.h: for Csound internals

Allows full access to everything. You should never include this header in
anything other than the files in Engine/, OOps/, Top/, and non-plugin files
in InOut/.

> Also, at the moment with the current SConstruct files, all .h files
> seem to be installed into /usr/local/include/csound which seems a bit
> overkill.  I think it'd be great if we could start putting together a
> separate opcode SDK package that has a very simple plugin opcode with
> Makefile--which I think is plenty enough for an opcode plugin--that
> can compile using just what will be installed, to help encourse
> external opcode building.

I will change SConstruct to install only those files from H/ that are
needed by csound.h and csdl.h. However, I am not familiar with CsoundVST,
so all headers of CsoundVST will still be installed.


-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Michael Gogins
In reply to this post by Steven Yi
I agree with Steven that there should be one header file usable by hosts and clients.

I agree with Istvan that there should be an API (high-level) that hides internals of the CSOUND structure, and that there should be another (low-level) API that exposes details of the CSOUND structure.

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.

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

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

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.

Except for the plugin opcode header files, there is probably no need for any other header files in the Csound build. All the existing ones could be combined into the "complete" header.

Best,
Mike

-----Original Message-----
From: Steven Yi <[hidden email]>
Sent: Aug 17, 2005 1:44 AM
To: Csound-dev <[hidden email]>
Subject: [Cs-dev] csound.h

Hi All,

Regarding CS5 and a release, I think one thing that should be
addressed is the csound.h file.  I know with Matt's MacCsound, all
things necessary for either a plugin or host is contained in csound.h.
 I think this would be ideal.  Currently there's a split between
csound.h and csoundCore.h.  Any thoughts?

Also, at the moment with the current SConstruct files, all .h files
seem to be installed into /usr/local/include/csound which seems a bit
overkill.  I think it'd be great if we could start putting together a
separate opcode SDK package that has a very simple plugin opcode with
Makefile--which I think is plenty enough for an opcode plugin--that
can compile using just what will be installed, to help encourse
external opcode building.

Thanks,
steven


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Istvan Varga
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Michael Gogins
In reply to this post by Steven Yi
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 <[hidden email]>
Sent: Aug 17, 2005 10:30 AM
To: [hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Istvan Varga
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Michael Gogins
In reply to this post by Steven Yi
OK, that should work.

I think Steven still has a point with simplifying the headers for clients of the API. I can easily imagine clients that need to #include <csdl.h> and this brings in many other headers, no?

By the way, CsoundVST with latest CVS sources is building and working. I only had to make one minor change (the output soundfile name is now being blanked out after csound finishes running so I have to save it in CsoundVST after compiling). So, thanks for your attention to CsoundVST when changing the ENVIRON to CSOUND.

Regards,
Mike

-----Original Message-----
From: Istvan Varga <[hidden email]>
Sent: Aug 17, 2005 11:46 AM
To: [hidden email]
Subject: Re: [Cs-dev] csound.h

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Anthony Kozar
In reply to this post by Istvan Varga
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Istvan Varga
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Istvan Varga
In reply to this post by Michael Gogins
Michael Gogins wrote:

> By the way, CsoundVST with latest CVS sources is building and
> working. I only had to make one minor change (the output soundfile
> name is now being blanked out after csound finishes running so I have
> to save it in CsoundVST after compiling). So, thanks for your
> attention to CsoundVST when changing the ENVIRON to CSOUND.

I made a number of changes to CsoundVST sources to fix compile
errors, although the main issue was not the renaming of ENVIRON to
CSOUND (this was done with a simple program that was run on all source
files), but the replacement of void* instance pointers with ENVIRON*
(now CSOUND*) and some of the header changes.


-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Steven Yi
Hi All,

Thanks all for chiming in with comments. I think having the csound.h
and csdl.h is fine, just would like to get the opcode and host
developer roles more clearly defined so that some SDK's could start
being made with detailed instructions.  Having only the required
headers installed for development is a big plus to making the point of
entry for developing against Csound lower, I think.

Also, certain macros need to be defined for those headers to work out
correctly, yes?  If I am building a separate application, what's the
best way to convey those macros which need to be defined?

steven

On 8/17/05, Istvan Varga <[hidden email]> wrote:

> Michael Gogins wrote:
>
> > By the way, CsoundVST with latest CVS sources is building and
> > working. I only had to make one minor change (the output soundfile
> > name is now being blanked out after csound finishes running so I have
> > to save it in CsoundVST after compiling). So, thanks for your
> > attention to CsoundVST when changing the ENVIRON to CSOUND.
>
> I made a number of changes to CsoundVST sources to fix compile
> errors, although the main issue was not the renaming of ENVIRON to
> CSOUND (this was done with a simple program that was run on all source
> files), but the replacement of void* instance pointers with ENVIRON*
> (now CSOUND*) and some of the header changes.
>
>
> -------------------------------------------------------
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Michael Gogins
In reply to this post by Steven Yi
The easiest way to do this is to use the existing SConstruct file and modify it -- add your app or plugin as a new target. You can copy the SCons code for an existing plugin opcode to make a new plugin opcode, copy the CsoundVST SCsons code or csound_main SCons code to make a new host application using Csound, etc. The SCons code will know the macros.

There may, I vaguely recall, be a way to write a new SConstruct that can read the existing one for the environment... I'll look into that....

Regards,
Mike

-----Original Message-----
From: Steven Yi <[hidden email]>
Sent: Aug 17, 2005 1:58 PM
To: [hidden email]
Subject: Re: [Cs-dev] csound.h

Hi All,

Thanks all for chiming in with comments. I think having the csound.h
and csdl.h is fine, just would like to get the opcode and host
developer roles more clearly defined so that some SDK's could start
being made with detailed instructions.  Having only the required
headers installed for development is a big plus to making the point of
entry for developing against Csound lower, I think.

Also, certain macros need to be defined for those headers to work out
correctly, yes?  If I am building a separate application, what's the
best way to convey those macros which need to be defined?

steven

On 8/17/05, Istvan Varga <[hidden email]> wrote:

> Michael Gogins wrote:
>
> > By the way, CsoundVST with latest CVS sources is building and
> > working. I only had to make one minor change (the output soundfile
> > name is now being blanked out after csound finishes running so I have
> > to save it in CsoundVST after compiling). So, thanks for your
> > attention to CsoundVST when changing the ENVIRON to CSOUND.
>
> I made a number of changes to CsoundVST sources to fix compile
> errors, although the main issue was not the renaming of ENVIRON to
> CSOUND (this was done with a simple program that was run on all source
> files), but the replacement of void* instance pointers with ENVIRON*
> (now CSOUND*) and some of the header changes.
>
>
> -------------------------------------------------------
> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Istvan Varga
In reply to this post by Steven Yi
Steven Yi wrote:

> Also, certain macros need to be defined for those headers to work out
> correctly, yes?  If I am building a separate application, what's the
> best way to convey those macros which need to be defined?

You do not need to define macros to select the type of interface (host
or plugin) to be used; rather than that, the interface is selected by
including csound.h or csdl.h. I also changed sysdep.h to make it work
- at least for externals - even without the various system dependent
macros (LINUX, WIN32, HAVE_*, etc.), although defining macros may still
be needed on Mac platforms or compilers other than GCC.
USE_DOUBLE should be defined when compiling for a double precision
Csound library.



-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Istvan Varga
In reply to this post by Anthony Kozar
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: csound.h

Steven Yi
In reply to this post by Michael Gogins
This is easiest now, but I really don't think this should be the
recommended way to do it.  I would prefer the development model to be
like any other Linux package.  Ideally, this is what I am imagining:

csound5.rpm - all binary utilities
csound5-src.rpm - src rpm release
csound5-devel.rpm - all headers

You can install those, and after that the user would have everything
they would need to run csound as well as compile a csound host or
opcode.  The user, IMO, should not ever have to touch SConstruct file
that comes with Csound, let alone know anything about it.  They should
only need to know the API and the csound.h and csdl.h headers.  They
should be free to use whatever dev environment the would like for
compiling their opcode library (for instance, I'd rather use Eclipse's
C Development environment and use the managed make mode for creating
an opcode plugin, rather than write a makefile).  I think that would
make it easiest for users to develop against csound, IMO.

I've done a simple opcode port to cs5 using a simple Makefile and
using an #include <csound/csdl.h> header and it was *much* simpler
than dealing with learning SConstruct and all that.

steven

On 8/17/05, Michael Gogins <[hidden email]> wrote:

> The easiest way to do this is to use the existing SConstruct file and modify it -- add your app or plugin as a new target. You can copy the SCons code for an existing plugin opcode to make a new plugin opcode, copy the CsoundVST SCsons code or csound_main SCons code to make a new host application using Csound, etc. The SCons code will know the macros.
>
> There may, I vaguely recall, be a way to write a new SConstruct that can read the existing one for the environment... I'll look into that....
>
> Regards,
> Mike
>
> -----Original Message-----
> From: Steven Yi <[hidden email]>
> Sent: Aug 17, 2005 1:58 PM
> To: [hidden email]
> Subject: Re: [Cs-dev] csound.h
>
> Hi All,
>
> Thanks all for chiming in with comments. I think having the csound.h
> and csdl.h is fine, just would like to get the opcode and host
> developer roles more clearly defined so that some SDK's could start
> being made with detailed instructions.  Having only the required
> headers installed for development is a big plus to making the point of
> entry for developing against Csound lower, I think.
>
> Also, certain macros need to be defined for those headers to work out
> correctly, yes?  If I am building a separate application, what's the
> best way to convey those macros which need to be defined?
>
> steven
>
> On 8/17/05, Istvan Varga <[hidden email]> wrote:
> > Michael Gogins wrote:
> >
> > > By the way, CsoundVST with latest CVS sources is building and
> > > working. I only had to make one minor change (the output soundfile
> > > name is now being blanked out after csound finishes running so I have
> > > to save it in CsoundVST after compiling). So, thanks for your
> > > attention to CsoundVST when changing the ENVIRON to CSOUND.
> >
> > I made a number of changes to CsoundVST sources to fix compile
> > errors, although the main issue was not the renaming of ENVIRON to
> > CSOUND (this was done with a simple program that was run on all source
> > files), but the replacement of void* instance pointers with ENVIRON*
> > (now CSOUND*) and some of the header changes.
> >
> >
> > -------------------------------------------------------
> > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel