I want to compile and debug Csound - the executable and its library, or at least whichever one or more libraries hold the ugens.

This is on Debian Linux, with the Codelite IDE.  (Codelite is the only IDE I know of which enables traditional GUI debugging with gdb, with pretty printing of C++ containers, while also enabling direct text-mode (not the computer interface) access to gdb.

I was able to get partway towards this.  I used:

to create a Codelite workspace file and a Codelite project file from the supplied CMakeLists.txt file.

The -B "build" instructed it to put both files in a subdirectory I made: build/,  which worked fine.

The graphvis command produced some graphs in an obscure format which I was able to convert (at least the first of many files) to a PDF, with dot -Tpdf Csound.dot -o Csound.pdf.  The resulting PDF was 2.8 metres wide and only a few cm tall: https://www.firstpr.com.au/temp/csound/Csound-graphviz-dependencies.pdf  I printed it and will scrutinise it later.

Codelite 17.0.0 worked OK with this, but all the executables and libraries wound up in build/.  Based on prior experience with Codelite projects which I had made myself, for my own source code, I was expecting to be able to alter the project file (by using Codelite itself, generally not by manually editing the file) to have two build configurations: Release and Debug, with appropriate compiler options, with the executables being built in build/Debug/ and build/Release/ respectively.  However, this seems to be impossible since the build process ignores various project file settings I use to do this.  The details are complex and I have only a cursory understanding of all the things going on with the resulting project file and its custom build settings which cause compilation to occur via some call of gmake, using cmake-produced CMakeLists.txt files in the various directories which hold the source code.

There's no obvious way of altering this extremely complex setup to produce a debug version of the Csound executable and its library or libraries or to have this with a separate Release build as well.

If anyone can suggest a way forward, I would greatly appreciate it.

One option might be to cut the whole source tree down to whatever I need (no Java or whatever) to build whatever constitutes Csound itself, with no other programs.  Then, if I can sort out whatever all the dependencies need me to do to my Codelite project, I can let Codelite figure out now to build it, using whatever arrangements it normally uses, without relying at all on the supplied CMakeLists.txt file.  Then I can set up the Debug and Release directories and compiler options as I normally do.

I want to add an old, complex, set of ugens to current Csound.  When I wrote these in 1996, they required some extra code in the guts of the program, so they are not ordinary ugens.  In 1998 I was able to integrate them with Csound 3.482, but a lot has changed since then!

I could probably do this without a debugger, but I want to extend these already complex ugens, so it would be best to be able to debug them properly.

I will be using the results with Cabbage, with which I made: https://www.youtube.com/watch?v=31DHfo8g9Sw a few years ago.   In 1996 I used Csound to make https://www.youtube.com/watch?v=05nJ7Ze1IHE and https://www.youtube.com/watch?v=yBhuwZGMx0w.

  Best regards

     Robin

Hi Robin,

I am not familiar with using the graphviz option on CMake, so I can’t comment on that. 

As for CodeLite generators, I see it’s what CMake calls an “extra generator”, 

https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#extra-generators

where the main generator is a Makefile (in your case). It seems to be deprecated though

"Deprecated since version 3.27: Support for "Extra Generators" is deprecated and will be removed from a future version of CMake. 
IDEs may use the cmake-file-api(7) to view CMake-generated project build trees."

This CMake variable seems to be relevant:

https://cmake.org/cmake/help/latest/variable/CMAKE_CODELITE_USE_TARGETS.html#variable:CMAKE_CODELITE_USE_TARGETS

Unfortunately, I don’t use any IDEs (including CodeLite) so can’t help you more with that. I can however say a few things in general that may be helpful.

1. Building Csound: by far the easiest way to build Csound on Linux is to generate a Makefile from CMake, then use make to build it and install it. You
can give a custom.cmake (there is an example in the sources) with all the build options you require.

2. As you noted, Csound has changed a lot since 96, and so working with the codebase has changed as well. In general, new opcodes are just built
as plugins. There is a module API that has all the support we need to build any opcode without having to make any internal modifications. In theory 
all opcodes in the current code base (Csound 7.0) can be built as plugins, but we still have a certain amount of so-called “internal” opcodes because
either it makes more sense for us to maintain them in that way or because we never got around to make them optionally as plugins (there is only a
few of us who actively maintain the code).

3. Given that, you should just be able to build the library, install it, and then build your plugins to run in Csound. Plugins do not need to be linked, all
you need is the public headers (basically including csdl.h) to build them. They can be dropped into a designated plugin directory or loaded directly
from a Csound option. This is also handy when you want to distribute your collection.

4. Also due to the restrictions we have in terms of maintaining the codebase, we promote third-party opcode development. In general, any new opcodes that
are proposed (via say a PR) to the Csound codebase will need to pass a strict review process in order for the contribution to be taken in. That of course applies
to any code, not only opcodes, but particularly with opcodes, there are curatorial considerations as we want to make sure there is no explosion of “similar but not quite” opcodes in the sources, which has been historically an issue with Csound.

So in summary, it’s great to hear that you’re interested in working on new opcodes, and we would like to provide support for that. I would suggest that there is
no need to create custom builds of Csound to achieve what you are planning. Building a debug version of Csound and installing it may be sufficient. You can
set the relevant CMake options for that.

best regards
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 11 Sep 2024, at 15:53, Robin Whittle  wrote:
> 
> You don't often get email from rw@firstpr.com.au. Learn why this is important *Warning*
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> I want to compile and debug Csound - the executable and its library, or at least whichever one or more libraries hold the ugens.
> This is on Debian Linux, with the Codelite IDE.  (Codelite is the only IDE I know of which enables traditional GUI debugging with gdb, with pretty printing of C++ containers, while also enabling direct text-mode (not the computer interface) access to gdb.
> I was able to get partway towards this.  I used:
> cmake -G "CodeLite - Unix Makefiles" -B "build"  --graphviz="z-graphviz/Csound.dot" .
> to create a Codelite workspace file and a Codelite project file from the supplied CMakeLists.txt file.
> The -B "build" instructed it to put both files in a subdirectory I made: build/,  which worked fine. 
> The graphvis command produced some graphs in an obscure format which I was able to convert (at least the first of many files) to a PDF, with dot -Tpdf Csound.dot -o Csound.pdf.  The resulting PDF was 2.8 metres wide and only a few cm tall: https://www.firstpr.com.au/temp/csound/Csound-graphviz-dependencies.pdf  I printed it and will scrutinise it later. 
> 
> Codelite 17.0.0 worked OK with this, but all the executables and libraries wound up in build/.  Based on prior experience with Codelite projects which I had made myself, for my own source code, I was expecting to be able to alter the project file (by using Codelite itself, generally not by manually editing the file) to have two build configurations: Release and Debug, with appropriate compiler options, with the executables being built in build/Debug/ and build/Release/ respectively.  However, this seems to be impossible since the build process ignores various project file settings I use to do this.  The details are complex and I have only a cursory understanding of all the things going on with the resulting project file and its custom build settings which cause compilation to occur via some call of gmake, using cmake-produced CMakeLists.txt files in the various directories which hold the source code.
> There's no obvious way of altering this extremely complex setup to produce a debug version of the Csound executable and its library or libraries or to have this with a separate Release build as well.
> If anyone can suggest a way forward, I would greatly appreciate it.
> One option might be to cut the whole source tree down to whatever I need (no Java or whatever) to build whatever constitutes Csound itself, with no other programs.  Then, if I can sort out whatever all the dependencies need me to do to my Codelite project, I can let Codelite figure out now to build it, using whatever arrangements it normally uses, without relying at all on the supplied CMakeLists.txt file.  Then I can set up the Debug and Release directories and compiler options as I normally do.
> 
> I want to add an old, complex, set of ugens to current Csound.  When I wrote these in 1996, they required some extra code in the guts of the program, so they are not ordinary ugens.  In 1998 I was able to integrate them with Csound 3.482, but a lot has changed since then!
> I could probably do this without a debugger, but I want to extend these already complex ugens, so it would be best to be able to debug them properly.
> 
> I will be using the results with Cabbage, with which I made: https://www.youtube.com/watch?v=31DHfo8g9Sw a few years ago.   In 1996 I used Csound to make https://www.youtube.com/watch?v=05nJ7Ze1IHE and https://www.youtube.com/watch?v=yBhuwZGMx0w. 
> 
>   Best regards
>      Robin
> 
> 
> 
> 
> 
> 
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Victor,

Thanks very much for your reply.  The opcodes I have, and was considering extending, were just for my own use.

Looking quickly at BUILD.md and Custom.cmake.ex I get the impression that I could use cmake with a suitably modified Custom.cmake file to create a pair of Codelite workspace and project files which would use compiler flags for debuggable executables and libraries.

Since Csound needs to be compiled on such a range of CPUs and operating systems, and relies on a large and variable set of libraries, which themselves are frequently being changed, producing not just an executable and its runtime library (which I think Cabbage and other programs can interface to directly), but multiple other helper programs, it is necessary to have a suitably complex build arrangement.  As best I understand it, this centres on cmake operating from a carefully hand-crafted CMakeLists.txt to produce makefiles from which make (in practice, on Linux, gmake) actually does the work of compiling everything, and in a separate step, installing the executables and runtime libraries.

The CMake documentation https://cmake.org/cmake/help/latest/index.html looks to me like it is helpfully structured and well-maintained, but life is too short for me to become even partially adept at using it.  It makes perfect sense that something as extensive as this is required to cover all or most of things which are required for complex software projects.  However the extensive nature of the documentation https://cmake.org/cmake/help/latest/genindex.html is daunting, especially since even with completely coherent, up-to-date, documentation, it can be very challenging to understand and use any such complex system.

Its great that ugens can now be added without compiling the whole program.  Curating a suitably comprehensive but interoperable set of ugens must be difficult.

If I was determined to use and extend my ugens in Csound, I would pursue a complete compilation system in which I could produce Release and Debug builds from Codelite.  My opcodes involve some intercommunication and some other things which required extra code in the program, so I guess this would still make it impossible to implement them without altering the guts of Csound itself.

However, my aim was to find a relatively easy way of using my ugens and potentially expanding them, as a first step to implementing them in a completely new system.  Since it looks tricky to implement debugging under Codelite, I probably won't pursue working directly with the Csound code.

The trouble with Csound and - as far as I know, all other music programming languages - is that they have specific constructs which are necessary for real-time and/or file read and write generation of musical signals, which makes them suitable for such use, but that the languages lack the fulsome nature of C++, such as the ability to call general purpose functions and work with general purpose, user-defined, data types.  C++'s containers library is a tremendously powerful capability, with debugging support for IDE debug "pretty printing" of arbitrarily complex classes involving complex data structures.  As far as I know, no other language has this.

I envisage doing the sorts of things which can be done in Csound, entirely in C++, with suitable libraries of functions for file and real-time I/O, communication with Cabbage or perhaps some other GUI interface.  I have no experience in GUI programming, so hopefully I will be able to use or adapt an existing system, which ideally would be able to record and play in some way with a DAW (Ardour).

I am a long way from creating the system I want - and I have been intending to do so since 1996!

  Best regards

     Robin

Hi Robin,

I am not familiar with using the graphviz option on CMake, so I can’t comment on that. 

As for CodeLite generators, I see it’s what CMake calls an “extra generator”, 

https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#extra-generators

where the main generator is a Makefile (in your case). It seems to be deprecated though

"Deprecated since version 3.27: Support for "Extra Generators" is deprecated and will be removed from a future version of CMake. 
IDEs may use the cmake-file-api(7) to view CMake-generated project build trees."

This CMake variable seems to be relevant:

https://cmake.org/cmake/help/latest/variable/CMAKE_CODELITE_USE_TARGETS.html#variable:CMAKE_CODELITE_USE_TARGETS

Unfortunately, I don’t use any IDEs (including CodeLite) so can’t help you more with that. I can however say a few things in general that may be helpful.

1. Building Csound: by far the easiest way to build Csound on Linux is to generate a Makefile from CMake, then use make to build it and install it. You
can give a custom.cmake (there is an example in the sources) with all the build options you require.

2. As you noted, Csound has changed a lot since 96, and so working with the codebase has changed as well. In general, new opcodes are just built
as plugins. There is a module API that has all the support we need to build any opcode without having to make any internal modifications. In theory 
all opcodes in the current code base (Csound 7.0) can be built as plugins, but we still have a certain amount of so-called “internal” opcodes because
either it makes more sense for us to maintain them in that way or because we never got around to make them optionally as plugins (there is only a
few of us who actively maintain the code).

3. Given that, you should just be able to build the library, install it, and then build your plugins to run in Csound. Plugins do not need to be linked, all
you need is the public headers (basically including csdl.h) to build them. They can be dropped into a designated plugin directory or loaded directly
from a Csound option. This is also handy when you want to distribute your collection.

4. Also due to the restrictions we have in terms of maintaining the codebase, we promote third-party opcode development. In general, any new opcodes that
are proposed (via say a PR) to the Csound codebase will need to pass a strict review process in order for the contribution to be taken in. That of course applies
to any code, not only opcodes, but particularly with opcodes, there are curatorial considerations as we want to make sure there is no explosion of “similar but not quite” opcodes in the sources, which has been historically an issue with Csound.

So in summary, it’s great to hear that you’re interested in working on new opcodes, and we would like to provide support for that. I would suggest that there is
no need to create custom builds of Csound to achieve what you are planning. Building a debug version of Csound and installing it may be sufficient. You can
set the relevant CMake options for that.

best regards
========================
Prof. Victor Lazzarini
Maynooth University
Ireland



Hi Victor,

Thanks very much for your reply.  The opcodes I have, and was considering extending, were just for my own use.

Looking quickly at BUILD.md and Custom.cmake.ex I get the impression that I could use cmake with a suitably modified Custom.cmake file to create a pair of Codelite workspace and project files which would use compiler flags for debuggable executables and libraries.

Since Csound needs to be compiled on such a range of CPUs and operating systems, and relies on a large and variable set of libraries, which themselves are frequently being changed, producing not just an executable and its runtime library (which I think Cabbage and other programs can interface to directly), but multiple other helper programs, it is necessary to have a suitably complex build arrangement.  As best I understand it, this centres on cmake operating from a carefully hand-crafted CMakeLists.txt to produce makefiles from which make (in practice, on Linux, gmake) actually does the work of compiling everything, and in a separate step, installing the executables and runtime libraries.

The CMake documentation https://cmake.org/cmake/help/latest/index.html looks to me like it is helpfully structured and well-maintained, but life is too short for me to become even partially adept at using it.  It makes perfect sense that something as extensive as this is required to cover all or most of things which are required for complex software projects.  However the extensive nature of the documentation https://cmake.org/cmake/help/latest/genindex.html is daunting, especially since even with completely coherent, up-to-date, documentation, it can be very challenging to understand and use any such complex system.

Its great that ugens can now be added without compiling the whole program.  Curating a suitably comprehensive but interoperable set of ugens must be difficult.

If I was determined to use and extend my ugens in Csound, I would pursue a complete compilation system in which I could produce Release and Debug builds from Codelite.  My opcodes involve some intercommunication and some other things which required extra code in the program, so I guess this would still make it impossible to implement them without altering the guts of Csound itself.

However, my aim was to find a relatively easy way of using my ugens and potentially expanding them, as a first step to implementing them in a completely new system.  Since it looks tricky to implement debugging under Codelite, I probably won't pursue working directly with the Csound code.

The trouble with Csound and - as far as I know, all other music programming languages - is that they have specific constructs which are necessary for real-time and/or file read and write generation of musical signals, which makes them suitable for such use, but that the languages lack the fulsome nature of C++, such as the ability to call general purpose functions and work with general purpose, user-defined, data types.  C++'s containers library is a tremendously powerful capability, with debugging support for IDE debug "pretty printing" of arbitrarily complex classes involving complex data structures.  As far as I know, no other language has this.

I envisage doing the sorts of things which can be done in Csound, entirely in C++, with suitable libraries of functions for file and real-time I/O, communication with Cabbage or perhaps some other GUI interface.  I have no experience in GUI programming, so hopefully I will be able to use or adapt an existing system, which ideally would be able to record and play in some way with a DAW (Ardour).

I am a long way from creating the system I want - and I have been intending to do so since 1996!

  Best regards

     Robin

On 2024-09-12 2:52 am, Victor Lazzarini wrote:

Hi Robin,

I am not familiar with using the graphviz option on CMake, so I can’t comment on that. 

As for CodeLite generators, I see it’s what CMake calls an “extra generator”, 

https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#extra-generators

where the main generator is a Makefile (in your case). It seems to be deprecated though

"Deprecated since version 3.27: Support for "Extra Generators" is deprecated and will be removed from a future version of CMake. 
IDEs may use the cmake-file-api(7) to view CMake-generated project build trees."

This CMake variable seems to be relevant:

https://cmake.org/cmake/help/latest/variable/CMAKE_CODELITE_USE_TARGETS.html#variable:CMAKE_CODELITE_USE_TARGETS

Unfortunately, I don’t use any IDEs (including CodeLite) so can’t help you more with that. I can however say a few things in general that may be helpful.

1. Building Csound: by far the easiest way to build Csound on Linux is to generate a Makefile from CMake, then use make to build it and install it. You
can give a custom.cmake (there is an example in the sources) with all the build options you require.

2. As you noted, Csound has changed a lot since 96, and so working with the codebase has changed as well. In general, new opcodes are just built
as plugins. There is a module API that has all the support we need to build any opcode without having to make any internal modifications. In theory 
all opcodes in the current code base (Csound 7.0) can be built as plugins, but we still have a certain amount of so-called “internal” opcodes because
either it makes more sense for us to maintain them in that way or because we never got around to make them optionally as plugins (there is only a
few of us who actively maintain the code).

3. Given that, you should just be able to build the library, install it, and then build your plugins to run in Csound. Plugins do not need to be linked, all
you need is the public headers (basically including csdl.h) to build them. They can be dropped into a designated plugin directory or loaded directly
from a Csound option. This is also handy when you want to distribute your collection.

4. Also due to the restrictions we have in terms of maintaining the codebase, we promote third-party opcode development. In general, any new opcodes that
are proposed (via say a PR) to the Csound codebase will need to pass a strict review process in order for the contribution to be taken in. That of course applies
to any code, not only opcodes, but particularly with opcodes, there are curatorial considerations as we want to make sure there is no explosion of “similar but not quite” opcodes in the sources, which has been historically an issue with Csound.

So in summary, it’s great to hear that you’re interested in working on new opcodes, and we would like to provide support for that. I would suggest that there is
no need to create custom builds of Csound to achieve what you are planning. Building a debug version of Csound and installing it may be sufficient. You can
set the relevant CMake options for that.

best regards
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here