csound / plugins

Repository for Csound plugins which were originally in the main repository, and for new plugins as well.

CSOUND

Version 6.18.0

A sound and music computing system.

Csound is copyright (c) 1991-2020 The Csound Developers, see CONTRIBUTORS

Csound is free software; you can redistribute them and/or modify them under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

Csound is distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this software; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

GETTING STARTED

This repository contains the code for the core Csound library, the interfaces library, and the command-line interface frontend. It also contains specific code for ports to various embedded, mobile and web platforms.

For general project information, please look at http://csound.com, where all details about Csound, what it does, its history, music made with it, and many other things can be found.

The Csound Reference Manual can be found online at http://docs.csound.com.

The Csound API application programming interface reference may be found online at http://csound.github.io/docs/api/index.html.

Information on how to build Csound on various platforms is given in the BUILD.md file at the top level directory of this repository.

Information about build pipelines with Azure and Github actions is given in DockerFiles/Readme.md.

CONTRIBUTORS

Csound contains contributions from musicians, scientists, and programmers from around the world. They include (but are not limited to):

• Allan Lee
• Andres Cabrera
• Anthony Kozar
• Barry Vercoe
• Bill Gardner
• Bill Verplank
• Dan Ellis
• David Macintyre
• Ed Costello
• Eli Breder
• Fabio P. Bertolotti
• Felipe Sataler
• François Pinot
• Gabriel Maldonado
• Greg Sullivan
• Hans Mikelson
• Henri Manson
• Ian McCurdy
• Istvan Varga
• Jean Piché
• Joachim Heintz
• John Ramsdell
• John ffitch
• Marc Resibois
• Mark Dolson
• Matt Ingalls
• Max Mathews
• Michael Casey
• Michael Clark
• Michael Gogins
• Mike Berry
• Nate Whetsell
• Paris Smaragdis
• Perry Cook
• Peter Neubäcker
• Peter Nix
• Rasmus Ekman
• Richard Dobson
• Richard Karpen
• Rob Shaw
• Robin Whittle
• Rory Walsh
• Sean Costello
• Stephen Kyne
• Steven Yi
• Tito Latini
• Tom Erbe
• Victor Lazzarini
• Ville Pulkki

plugins's Issues

make install path has error

make install copies plugin so-files to the impossible path. Notice the space in between:

 /usr/local/ /usr/local/lib/csound/plugins64-6.0/libfluidOpcodes.so

Build failed with GCC 14

/build/csound-plugins/src/plugins-1.0.2/hdf5/HDF5IO.c: In function ‘HDF5IO_readStringAttribute’:
/build/csound-plugins/src/plugins-1.0.2/hdf5/HDF5IO.c:233:39: error: passing argument 2 of ‘H5Oget_info1’ from incompatible pointer type [-Wincompatible-pointer-types]
  233 |     HDF5ERROR(H5Oget_info1(dataSetID, &oinfo));
      |                                       ^~~~~~
      |                                       |
      |                                       H5O_info2_t *
/usr/include/csound/sysdep.h:345:45: note: in definition of macro ‘UNLIKELY’
  345 | #  define UNLIKELY(x)   __builtin_expect(!!(x),0)
      |                                             ^
/build/csound-plugins/src/plugins-1.0.2/hdf5/HDF5IO.c:233:5: note: in expansion of macro ‘HDF5ERROR’
  233 |     HDF5ERROR(H5Oget_info1(dataSetID, &oinfo));
      |     ^~~~~~~~~
In file included from /usr/include/H5Apublic.h:21,
                 from /usr/include/hdf5.h:22,
                 from /build/csound-plugins/src/plugins-1.0.2/hdf5/HDF5IO.h:21:
/usr/include/H5Opublic.h:1854:55: note: expected ‘H5O_info1_t *’ but argument is of type ‘H5O_info2_t *’
 1854 | H5_DLL herr_t H5Oget_info1(hid_t loc_id, H5O_info1_t *oinfo);
      |                                          ~~~~~~~~~~~~~^~~~~

no way to configure csound path

if csound is not installed in the expected directory there is no way to configure that path.
It's mentioned in the DOCs that there are flags for that but they did not work.

csound7: missing OpcodeBase.hpp for chua

Where would I find this header file for csound7 builds?

Fatal error when VECLIB is missing

I guess this dependency should be optional?

CMake Error in p5glove/CMakeLists.txt:
  Found relative path while evaluating include directories of "p5g":

    "VECLIB_PATH-NOTFOUND"



CMake Error in p5glove/CMakeLists.txt:
  Found relative path while evaluating include directories of "p5g":

    "VECLIB_PATH-NOTFOUND"

New release?

Hello! As the newest csound has moved a lot of functionality over here it would be nice to have a release cut so packagers are on the same page.

Thanks!

Python opcodes no longer working on Windows..

I'm just posting this here to remind me to investigate the issue when I have a chance, but after building a new version with the latest build of csound I get an error when trying pyinit:

Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

When I prepared binaries for Windows in Aug 2021 these opcodes worked. I am using the same toolchain to build now as I did then, and I haven't changed or updated Python since. Anyone have ideas where I should start looking?

Plugins are installed to HOME

Hi! When looking into packaging this project for Arch Linux, I realized that the installation directory for the plugins is hardcoded to the caller's $HOME.
This is rather bad practice in regards to dealing with this in the context of cmake, as it does not allow for any sane override with the usual environment variables such as DESTDIR.

The default should always be to adhere to the system location (e.g. /usr/local) and if installing to a user's home is desired, then this should not be the norm, but be an optional feature.

CMake Error at src/widgets/CMakeLists.txt:22 (target_link_libraries):

I am trying to build csound-plugins for csound-6.18.1, and get

cmake ../csound-plugins -DCMAKE_INSTALL_PREFIX=/opt/csound/csound
-6.18.1 -DCSOUND_INCLUDE_DIR=/opt/csound/csound-6.18.1/include/csound -DUSE_FLTK=ON

...

-- USE_FLTK is enabled.
CMake Error at src/widgets/CMakeLists.txt:22 (target_link_libraries):
  The keyword signature for target_link_libraries has already been used with
  the target "widgets".  All uses of target_link_libraries with a target must
  be either all-keyword or all-plain.

  The uses of the keyword signature are here:

   * CMakeLists.txt:236 (target_link_libraries)



CMake Error at src/widgets/CMakeLists.txt:46 (target_link_libraries):
  The keyword signature for target_link_libraries has already been used with
  the target "virtual".  All uses of target_link_libraries with a target must
  be either all-keyword or all-plain.

  The uses of the keyword signature are here:

   * CMakeLists.txt:236 (target_link_libraries)

...
-- BUILD_P5GLOVE_OPCODES is disabled.        
-- BUILD_JACK_OPCODES is enabled.
-- BUILD_FLUID_OPCODES is enabled.             
-- Configuring incomplete, errors occurred!

I am using ca4e7a8 , and cmake version 3.25.1.

The above does NOT happen for master 27274a5 (cmake, make, make install all run but in the end, csound does not find the plugins)

fluidLoad does not free memory on Recompile

The manual states :

“Invoke fluidLoad in the orchestra header, any number of times. The same SoundFont may be invoked to assign programs to MIDI channels any number of times; the SoundFont is only loaded the first time.”

The problem is that every time I recompile (csoundCompileCsd() – api), the soundfont is reloaded in memory.
So, if a soundfont is p.e. 100MB, my RAM gets quickly full…

Any idea how to prevent this?

Building ableton-link opcode on Windows

I'm trying to build the ableton-link opcode with MSVC (Visual Studio 2022).I've turned off all the other opcodes.

When I build the Debug configuration I get link errors because of the --Wno-multichar and the --std=gnu++11 flags.
I suppose these configurations are meant for MinGW.

I've tried to adapt the CMake files for MSVC but with no luck.

I have also tried enabling vpkg but (I don't understand why) triggers the EIGEN3 requirement. I've downloaded it and configured the path but FindEIGEN3 still complains...

In the end, what's the proper setup to have these plugins compiled on Windows?

Usage of hdf5read crashes the instrument at compile time

Hello everybody
I’m using Cabbage as a frontend for CSound and I’m trying to user hdf5write/hdf5read to save and restore datas to disk.
In a test file I have a line like this:

printks"before hdf5read:\n", 0
;        aArray[], aVar, kVar hdf5read "f:/mypath/src/cabbage/example.h5", "aArray*", "aVar", "kVar" ; Open hdf5 file and read variables
printks"after hdf5read:\n", 0

but if I remove the comment Cabbage suddenly crashes without printing anything before, so it should be a compile time issue.
The same issue occurs when I use CSound standalone.

I’m running under the following SW stack:

Windows 10
CSound 6.16 (double samples) Jul 17 2021
Cabbage 2.8.0

I attach:

CSound instrument test_3.csd.txt
CSound output test_3.txt
Windows Event Viewer crash EventViewer.txt

Thank you in advance

Sergio

Binaries?

What's the chances we could get binaries for this? I see the pull request to update it for windows, but once that's done, if you're already shipping binaries for csound, you must have at least some infrastructure in place for that already?

Non-configurable install location prevents packaging on Homebrew

At commit 028c6e8, the value of PLUGIN_INSTALL_DIR (which determines where plug-ins are installed) was hard-coded to $HOME/Library/csound/<csound_version>/plugins64 on macOS when Csound uses double-precision samples. This means that plug-ins can’t be installed on macOS using Homebrew, as Homebrew does not permit installing files at that location. Not building Csound plug-ins using Homebrew isn’t really an option, as some Homebrew users rely on these plug-ins being there: https://listserv.heanet.ie/cgi-bin/wa?A1=ind2107&L=CSOUND-DEV#18. Please support a configurable PLUGIN_INSTALL_DIR.

Jacko hangs because of 'event'

i came across an issue that prevents me from using the Jacko opcodes making the Jack connections i want.
I want to use the Jacko opcodes in Blue, to use some external hardware synths via Midi. Now, Blue uses an 'event "e"' to tell the playbackhead to stop. As it turns out, Jacko does not like this and Csound does not stop at the designated time.

For this to test, i have attached several thing

1. event.csd - makes Csound crazy
2. Catia_JackConnection.png - showing the Jacko connection
3. Event_CPU.png - showing Csound going nuts
4. Event_NoStop.png - the output form Visual Studio Code, where (illegally) Jacko re-started after the csd has finished
5. no_event.csd - leaving out the 'event "e' and all works just fine

Images and csds:
JackoImages.zip
Jacko_csd.zip

The STKSitar opcode can create a buildup of clipped samples as illustrated by the attached csd file

as i don't have time right now to look into this myself, so I'm forwarding an oldish (6 years!) bug-report from Debian (here's the original bugreport), that appears to still be present in Csound-6.16

(i also reported this as csound/csound#1526 but was directed here)

The following CSD produces unexpected output: this may be a problem with
Csound, or STK, or both -- I'm filing this as a Csound bug because that's the
application I'm using when I experience the problem.

The CSD has two descending tone sequences played with the STKSitar opcode. The
duration of each note is 0.4 seconds and they are played 0.1 seconds apart, so
there should be no more than 4 notes playing simultaneously. Towards the end of
the first descending sequence, the volume shoots up dramatically, creating a
great deal of distortion.

There is a pause of 1.0 seconds before the second descending sequence, which
should be adequate for all notes from the first sequence to complete. Yet when
the second sequence plays, the distortion occurs almost immediately, on notes
which played without issue during the first tone sequence.

It appears that some sort of buffer is building up and not being flushed
adequately, but that's just speculation.

find the CSD in STKSitar_overflow.zip