Giter VIP home page Giter VIP logo

plugins's Introduction

CSOUND PLUGINS

This repository contains the code for Csound plugins that require external dependencies, as well as code for new third-party contributed plugins. This is actually very experimental and it should become fully effective in version 7 of Csound.

Currently, the plugins available in this tree are

  • AbletonLive Link (requires Ableton link)
    link_create link_enable link_is_enabled link_tempo_set link_tempo_get link_beat_get link_metro link_beat_request link_beat_force

  • chua (requires Eigen library, header-only)
    chuap

  • Faust (requires libfaust)
    faustgen faustcompile faustaudio faustdsp faustplay faustctl

  • image (requires libpng)
    imageload imagesave imagecreate imagesize imagegetpixel imagesetpixel imagefree

  • py (requires a Python 3.x installation with dev libs)
    Many opcodes to call Python code

  • widgets (requires the FLTK LIB)
    FLTK-based widgets.
    NB: These opcodes do not work correctly on MacOS due to incompatibilities with the operating system.

  • virtual keyboard (requires the FLTK LIB)
    Virtual MIDI keyboard midi backend

  • STK opcodes (requires STK library)
    Physical model opcodes using the STK library

Install location

The CMake scripts in this repository use the default CS_USER_PLUGIN location on MacOS and Windows as defined in the Csound build, or a library instalation directory (customisable) on LINUX. These are:

  • LINUX: depends on both CMAKE_INSTALL_PREFIX and USE_LIB64. It is then installed in:

    • if USE_LIB64=1 then to
      • for doubles: ${CSOUND_INSTALL_PREFIX}/lib64/csound/plugins64-${APIVERSION}
      • for floats: ${CSOUND_INSTALL_PREFIX}/lib64/csound/plugins-${APIVERSION} (floats)`
    • if USE_LIB64=0 then to
      • for doubles: ${CSOUND_INSTALL_PREFIX}/lib/csound/plugins64-${APIVERSION}
      • for floats: ${CSOUND_INSTALL_PREFIX}/lib/csound/plugins-${APIVERSION}
  • MACOS:

    • For doubles: $HOME/Library/csound/${APIVERSION}/plugins64
    • For floats: $HOME/Library/csound/${APIVERSION}/plugins
  • Windows:

    • For doubles: %LOCALAPPDATA%\csound\${APIVERSION}\plugins64
    • For floats: %LOCALAPPDATA%\csound\${APIVERSION}\plugins

Build Instructions for Linux and MacOS

The build requires Csound to be installed, as well as CMake. With this in place, you can do :

$ git clone https://github.com/csound/plugins.git
$ cd plugins
$ mkdir build
$ cd build
$ cmake ../
$ make

By default, all the plugins are built. If one wants to exclude a plugin from the build process, one can pass an option to the cmake command. For example, to exclude the chua plugin, the cmake command would be:

$ cmake -DBUILD_CHUA_OPCODES=OFF ../

For the FLTK dependent plugins, the configuration variable used is USE_FLTK.

To install the opcodes you have built

$ make install

Depending on your permissions, you might need to prepend sudo to these commands. After the first build the plugins can be updated with

$ git pull
$ make
$ make install

using sudo in the last step if raised permissions are needed. On Linux, the installation location can be set with the relevant CMake variables as indicated above.

Csound Location

CMake will normally find the installed Csound headers (and library) automatically. However, if your Csound headers and library are not placed in the usual locations, you can use the following CMake option variables to tell CMake where they are:

CSOUND_INCLUDE_DIR_HINT

and

CSOUND_LIBRARY_DIR_HINT

plugins's People

Contributors

anton-k avatar fggp avatar gogins avatar jpffitch avatar kunstmusik avatar nwhetsell avatar rorywalsh avatar stekyne avatar vlazzarini avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

plugins's Issues

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

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

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?

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);
      |                                          ~~~~~~~~~~~~~^~~~~

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"

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.

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.

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?

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?

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)

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!

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

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.