lcoogan
/
flucoma-sc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into clients/inter_client_comms

Browse Source
nix
Owen Green 6 years ago
parent 8844be07b1 e3d9c3cfc0
commit 9c8b9c0dc5
2 changed files with 35 additions and 95 deletions
Show Stats Download Patch File Download Diff File

124
README.md
Unescape Escape View File

@ -1,132 +1,70 @@
# Fluid Corpus Manipulation: SuperCollider Objects Library
This repository hosts code for generating the SC objects and documentation resources for the Fluid Corpus Manipulation Project. Much of the actual code that does the exciting stuff lives in this repository's principal dependency, the [Fluid Corpus Manipulation Library](). What lives here are:
* A wrapper from our code to the SC API, that allows us to generate SC objects from a generic class.
* Stubs for producing SC objects for each 'client' in the Fluid Corpus Manipulation Library.
* CMake code for managing dependencies, building and packaging.
## I'm in a Hurry...
...and you already have a development environment set up, understand CMake, and have the SC source available?
Cool:
```
cmake -DSC_PATH=<location of your SC source> ..
make
```
You can either symbolically link the `release-packaging` directory into your SC extensions folder, or use CMake to generate a 'clean package' with `make install`.
This repository hosts code for generating the SC objects and documentation resources for the Fluid Corpus Manipulation Project. Much of the actual code that does the exciting stuff lives in this repository's principal dependency, the [Fluid Corpus Manipulation Library]().
## Pre-requisites
* [CMake](http://cmake.org) >= 3.11
* A C++ 14 compliant compiler for Mac or Windows (via XCode tools on Mac, and Visual Studio 17 >= 15.9 on Windows)
- [CMake](http://cmake.org) >= 3.11
- A C++ 14 compliant compiler for Mac or Windows (via XCode tools on Mac, and Visual Studio 17 >= 15.9 on Windows)
## Dependencies
* [SC Source Code](https://github.com/supercollider/supercollider): this is the only dependency we don't (optionally) manage for you, so there must be a version available to point to when you run, using the CMake Variable `SC_PATH` (see below). It can live anywhere on your file system.
- [SC Source Code](https://github.com/supercollider/supercollider): this is the only dependency we don't (optionally) manage for you, so there must be a version available to point to when you run, using the CMake Variable `SC_PATH` (see below). It can live anywhere on your file system.
These will be downloaded and configured automatically, unless you pass CMake a source code location on disk for each (see below):
* [Fluid Corpus Manipulation Library]()
* [Eigen](https://gitlab.com/libeigen/eigen) (3.3.5)
* [HISSTools Library](https://github.com/AlexHarker/HISSTools_Library)
Unless you are simultaneously committing changes to these dependencies (or are *seriously* worried about disk space), there is nothing to be gained by pointing to external copies, and the easiest thing to is let CMake handle it all.
## Building
- [Fluid Corpus Manipulation Library]()
- [Eigen](https://gitlab.com/libeigen/eigen) (3.3.5)
- [HISSTools Library](https://github.com/AlexHarker/HISSTools_Library)
Simplest possible build:
1. Download the SuperCollider source (>= 3.10.0) if you haven't already
2. Clone this repo
```
git clone <whereis this>
```
3. Change to the directory for this repo, make a build directory, and run CMake, passing in the location for the Max SDK
```
mkdir -p build && cd build
cmake -DSC_PATH=<location of your SC source> ..
```
At this point, CMake will set up your tool chain (i.e. look for compilers), and download all the dependencies.
An alternative to setting up / running CMake directly on the command line is to install the CMake GUI, or use to use the curses gui `ccmake`.
With CMake you have a choice of which build system you use.
* The default on Mac is `Unix Makefiles`, but you can use Xcode by passing `-GXcode` to CMake when you first run it.
* The default on Windows is the latest version of Visual Studio installed. However, Visual Studio can open CMake files directly as projects, which has some upsides. When used this way, CMake variables have to be set via a JSON file that MSVC will use to configure CMake.
## I'm in a Hurry...
When using `make`, then
```
make
```
will compile all objects ('targets', in CMake-ish). Alternatively, in Xcode or Visual Studio, running 'build' will (by default) build all objects. Note that these IDEs allow you to build both for debugging and for release, whereas with Makefiles, you need to re-run CMake and pass a `CMAKE_CONFIG` variable for different build types.
...and you already have a development environment set up, understand CMake, and have the SC source available?
Cool:
```
mkdir -p build && cd build
cmake -DSC_PATH=<location of your SC source> ..
make install
```
Will assemble a clean package in `release-packaging/FluidCorpusManipulation`.
This will assemble a clean package in `release-packaging/FluidCorpusManipulation`.
## Structure:
An alternative to setting up / running CMake directly on the command line is to install the CMake GUI, or use to use the curses GUI `ccmake`.
The top-level folders mostly correspond to those you would find in a typical Max package. Some more will appear when you compile (such as `externals` and possibly `docs`).
Also, with CMake you have a choice of which build system you use.
The main action is in `source`:
```
source
├── include
├── src
└── scripts
```
* `include` contains the header files for the FluCoMa-SC wrapper
* `src` contains a subfolder for each object to be generated; each of these subfolders has a `.cpp` stub and a `CMakeLists.txt`. The `.cpp` file name needs to match its parent folder.
* `scripts` contains CMake scripts (most significantly, `target_post.cmake`, which sets behaviours for all the objects).
- The default on macOS and Linux is `Unix Makefiles`. On macOS you can also use Xcode by passing `-GXcode` to CMake when you first run it.
- The default on Windows is the latest version of Visual Studio installed. However, Visual Studio can open CMake files directly as projects, which has some upsides. When used this way, CMake variables have to be set via a JSON file that MSVC will use to configure CMake.
## Using Manual Dependencies
## Development: Manual Dependencies
In some cases you may want to use your own copies of the required libraries. Unless specified, the build system will download these automatically. To bypass this behaviour, use the following cache variables:
If you're making changes to the Fluid Corpus Manipulation Library and testing against Max (and, hopefully, our other deployment environments), then it makes sense to have the source for this cloned somewhere else on your disk, so that you can commit and push changes, and ensure that they work in all environments. This would be the case, e.g., if you're developing a new client.
- `FLUID_PATH`: location of the Fluid Corpus Manipulation Library
- `FLUID_PARAMDUMP_PATH`: location of `flucoma_paramdump` repository (e.g. for debugging documentation generation)
- `EIGEN_PATH` location of the Eigen library
- `HISS_PATH` location of the HISSTools library
To bypass the automatic cloning of the Fluid Corpus Manipulation Library, we pass in the cache variable `FLUID_PATH`
For example, use this to us your own copy of the Fluid Corpus Manipulation Library:
```
cmake -DSC_PATH=<location of your SC source> -DFLUID_PATH=<location of Fluid Corpus Manipulation Library> ..
```
Note
1. You don't need to run CMake on the Fluid Corpus Manipulation Library first (well, you can, but it doesn't make any difference!). CMake's FetchContent facility will grab the targets from there, but won't look in its CMakeCache, so there should never be a conflict between the state of a build tree at `FLUID_PATH` and your build-tree here.
2. It is **up to you** to make sure the commits you have checked out in each repository make sense together. We use tags against release versions on the `master` branch, so – at the very least – these should line up (unless you're tracking down some regression bug or similar). In general, there is no guarantee, or likelihood, that mismatched tags will build or run, as architectural changes can, do, will happen...
### Dependencies of dependencies!
The same steps and considerations apply to manually managing the dependencies of the Fluid Corpus Manipulation Library itself. If these aren't explicitly passed whilst running CMake against this build tree, then CMake will download them itself against the tags / commits we develop against. Nevertheless, if you are in the process of making changes to these libraries and running against this (which is much less likely than above), then the CMake variables of interest are:
* `EIGEN_PATH` pointing to the location of Eigen on disk
* `HISS_PATH` pointing to the location of the HISSTools Library
To find out which branches / tags / commits of these we use, look in the top level `CMakeLists.txt` of the Fluid Corpus Manipulation Library for the `FetchContent_Declare` statements for each dependency.
# Vector instructions and CPU architecture.
Most types of CPU in common use support a range of specialised instructions for processing vectors of numbers at once, which can offer substantial speed gains. For instance, on Intel / AMD chips there have been a succession of such instruction sets (MMX, SSE, AVX and so on).
To find out which branches / tags / commits of these we use, look in the top level `CMakeLists.txt` of the Fluid Corpus Manipulation Library for the `FetchContent_Declare` statements for each dependency.
If you find objects causing 'illegal instruction' segmentation faults, it is likely that our default vector instruction flag isn't supported by your CPU.
## Compiling for different CPUs
### I'm in a hurry...
The build system generally assumes an x86 cpu with AVX instructions (most modern x86 CPUs). To build on another kind of CPU (e.g. older than 2012) you can use the `FLUID_ARCH` cache variable to pass specific flags to your compiler. For example use `-DFLUID_ARCH=-mnative` to optimize for your particular CPU.
And *only building for your own machine*? You want to enable the maximal set of CPU features for your machine without worrying? Using Clang / GCC?
Pass `-DFLUID_ARCH=-mnative` when you run CMake. This tells the compiler to figure out what instruction sets your personal CPU supports, and enable them. This implies a possible performance gain in return for a portability loss.
### More Detail
By default, on Intel / AMD, we enable AVX instructions (`-mavx` on clang/GCC; `/ARCH:AVX` on MSVC). These should work on all relatively recent CPUs (from, say, 2012 onwards). On Arm (with the Bela in mind), we use the following architecture flags:
For ARM, we use the following default set of flags (with the Bela in mind):
```
-march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon
```
If your needs are different, then these defaults can be overridden by passing the desired compiler flags to CMake via the `FLUID_ARCH` cache variable. Note that this variable expects you to pass arguments in a form suitable for your compiler, and currently performs no checking or validation.
* Clang and GCC options are generally the same, see https://clang.llvm.org/docs/ClangCommandLineReference.html
* See MSVC options here https://docs.microsoft.com/en-us/cpp/build/reference/arch-minimum-cpu-architecture?view=vs-2019
If your Intel / AMD chip is too old to support AVX, it probably still supports SSE. On Mac OS and Linux, `sysctl -a | grep cpu.feat` can be used to produce a list of the various features your CPU supports.
--
> This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).
> This project has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement No 725899).

2
include/SCBufferAdaptor.hpp
Unescape Escape View File

@ -69,6 +69,8 @@ public:
SCBufferAdaptor(SCBufferAdaptor&&) = default;
SCBufferAdaptor(index bufnum, World* world, bool rt = false)
: NRTBuf(world, bufnum, rt), mBufnum(bufnum), mWorld(world)
{}

Write Preview
Loading…
Cancel
Save