Simplify dependencies

[gogins]

Satisfying all dependencies for building csound-extended, which includes many components for several target environments using several languages, has become complex and fragile. This must be changed or I will continually be distracted from composing.

Consider the following options:

• Break csound-extended up into sub-projects in their own repositories. These would be roughly:
  • csound.node
  • CsoundAC
  • nudruz
  • Csound for Android
  • Opcodes.
• Remove the auto-updating scripts, or permit them them to fail, and make the CMake build check for dependencies and warn if any are not found, but without failing to build components whose dependencies are satisfied.
• Drop some components that I don't actually use much.

[gogins]

• [ ] csound-extended-ac
• [ ] csound-extended-aeolus
• [ ] csound-extended-android-app
• [ ] csound-extended-node
• [ ] csound-extended-nudruz
• [ ] csound-extended-opcodes
• [ ] csound-extended-silencio
• [ ] csound-extended-vst

[gogins]

The trouble with the above is inter-dependencies.

Add Scheme support?

[gogins]

First, get rid of some superfluous things.

• [x] LuaJIT opcodes.
• [x] Lua interface to CsoundAC.
• [x] Lua port of Silencio.
• [x] Lua examples.
• [x] LuaJIT scripting in CsoundProducer.hpp.
• [x] Dependency and submodule for examples.
• [x] Dependency and submodule for LuaJIT, see https://gist.github.com/myusuf3/7f645819ded92bda6677.
• [x] CsoundVST directory.
• [x] Dependency on Debian Csound packages, replacing this with a dependency upon the currently installed version of Csound.
• [x] Dependency and download for ASIO? No, Ableton Link uses it.
• [x] Dependency and download for PortAudio? No, Ableton Link uses it.
• [x] Remove references to Qt SDK and LuaJIT from all CMakeLists.txt files.
• [x] Update README.md files.
• [x] Clean clone, rebuild, install, and test.

.

[gogins]

• [x] Pick up node-addon-api and node-gyp from the environment.
• [x] Support only Python 3.5 and higher.

[gogins]

Python packaging is wrong. I'm now building the CsoundAC Python extension module correctly, but it's not being installed by CPack correctly. An experienced user would be able to sort this out.

[gogins]

I'm trying to find Python in csound-extended now just the same way as it is done in csound.

Okay, that works, although it's not really done properly. But as long as Csound builds CppSound for 2.7 it will work. I should get rid of all that.

[gogins]

There is now an issue with the STK opcodes. I will see if it really is an issue. I don't think so.

[gogins]

I should perhaps replace my WebAssembly build with the "canonical" one and put in a shim to preserve my API. On second thought, keep it, as MIDI has been implemented in csound_embind.hpp.

[gogins]

The WebAssembly build now works and Emscripten's node does not interfere with the system node.

[gogins]

I think I have a simpler plan for breaking things up, essentially based on build system and licenses, and not on anything else.

• [ ] csound-extended-android-app: Just the Csound for Android app.
• [ ] csound-extended: Everything built with CMake, or for Lisp and other other languages with dynamic runtimes; basically everthing but the Android app.
• [x] csound-aeolus as now.
• [x] csound-vst as now until I move to the vestige headers or to VST SDK 3.

[gogins]

I wonder about switching to GPL 3.0 to bring in Aeolus and VST.

[gogins]

https://developer.android.com/studio/projects/add-native-code\\https://developer.android.com/studio/projects/gradle-external-native-builds

[gogins]

This is nuts. I am trying to fix something is definitely mess but also definitely not broken, when I should be composing. I'm going to get this to build on my nice new little computer and let it go. Maybe I'll break it out into its own repository.

[gogins]

Closing this issue in favor of a simpler one.