One system to rule them all: Silence

[gogins]

Create a unified release of csound-extended that runs on WebAssembly in browsers, in NW.js, and in Linux hosted non-browser environments.

This highly desirable outcome, which would obsolete all other packages here, is currently stuck due to missing features in WebAssembly itself.

I will proceed with this issue when, and if, WebAssembly releases the following features:

1. Host bindings (WebIDL).
2. ECMA6 modules.
3. DOM binding -- this may have fallen off the table.
4. Actual pthreads.

[gogins]

I am renaming this issue to reflect its true purpose. Which is, to develop and maintain only one system that supports:

• Algorithmic composition in at least JavaScript and Common Lisp. C++, Python, and LuaJIT would be nice too.
• Integrated use of Csound for synthesis.
• Integrated use of HTML5 for user interfaces.
• Integrated post-processing and tagging for efficient music production.
• Run on Linux and Android, potentially on WebAssembly and OS X.
• Usable as a library.

Currently, there is no one development platform that supports all of these requirements:

• WebAssembly doesn't support Common Lisp yet and does not have, and may never have, a true DOM binding.
• Building ECL for Android only works with NDK r17c.
• CsoundHtml5 crashes for reasons that I have not been able to debug.

The closest I can come to satisfying all requirements at this time is csound.node.

It is essential that this system be easy to maintain, use standard languages, and work with other music software.

My name for the system has always been, and continues to be, Silence.

[gogins]

Actually, WebIDL bindings for WebAssembly would indeed provide access to any part of the DOM or other HTML5 APIs, which are specified in WebIDL.

The status of the WebIDL proposal may be found here: https://github.com/WebAssembly/webidl-bindings.

[gogins]

What is needed for WebAssemby to support Silence is:

1. Run Common Lisp.
2. Access the DOM.
3. Provide components/APIs in the form of ECMAScript modules.
4. Have a desktop runtime with filesystem access.

[gogins]

I have to admit, this has been really hard and has involved many immense wastes of time.

The snake in the Garden is everybody's desire, including mine, to run off and re-invent the wheel.

High points have been:

1. The use of Csound.
2. The use of HTML5.
3. The use of neo-Reimannian theory, especially Tymoczko and the Generalized Contextual Group.

The worlds to collide are: Csound, HTML5, Lisp, Android, WebAssembly, and music notation.

[gogins]

I wonder if I could use this as a library in Csound for Android?https://www.reddit.com/r/lisp/comments/b1wnn2/cl_repl_for_android_now_64bit_ssl_libs_included/ https://gitlab.com/eql/EQL5-Android/ https://github.com/josrr/crepl

[gogins]

The major issues are:

• Which language does the driving. In other words, the user writes some top level code that controls the piece. The top-level code can embed other code, but must run that embedded code. Currently, JavaScript is the best candidate for the top-level language, because it interfaces directly with the DOM and has a Csound interface.
• Linear algebra interfaces/libraries/support. Bindings for vectors and matrices are always a problem. Currently, there is no direct interface between vectors and matrices in CsoundAC (C++) and JavaScript, or between Common Lisp and C++ or JavaScript.
• Simplifying maintenance.

I regard HTML5 support in csound.node and Csound for Android as proven. Lisp is not yet fully integrated. Having a built in C++ compiler would solve a lot of problems.

[gogins]

Just in terms of Csound on the desktop, I'm considering ways to simplify things. CsoundHtml5 was better when it useed the Chromium Embedded Framework, now it crashes in simple cases. Having both CsoundHtml5 and csound.node is somewhat redundant. I use SciTE with custom commands to run .html files using NW.js with csound.node, .py files with ctcsound.py or the Python binding for CsoundAC, .lua files with the Lua binding for CsoundAC, or just plain .csd files with Csound.

I would be happy to find a better editor than SciTE that I could customize in the same way, and then drop CsoundHtml5.

None of this prejudices future developments with WebAssembly.

[gogins]

It looks as though, when I was evaluating code editors, I missed Atom's process-palette package. If this can do the job I will use it.

[gogins]

Getting Atom run a .csd properly was easy. Looking good!

[gogins]

Csound menu for Atom Editor:

• [x] Render CSD piece to audio
• [x] Render CSD piece to soundfile and edit soundfile
• [x] Render CSD piece to soundfile and post-process and edit soundfile
• [x] Make C++ piece
• [x] Make C++ piece and render to audio
• [x] Make C++ piece and render soundfile and edit soundfile
• [x] Make C++ piece and render soundfile and post-process and edit soundfile
• [x] Run HTML piece in NW.js
• [ ] Test .inc instrument definition

Lisp, Lua, and Python should not need to be in the Csound menu because they have their own Atom Editor packages.

[gogins]

I have removed CsoundHtml5 from the csound-extended repository and package, in favor of using a text editor with configurable commands, such as Atom Editor.

[gogins]

With CsoundHtml5 now gone, it remains to merge and/or duplicate functionality between the current state of Csound in a good editor with Android. Android currently lacks only Common Lisp support.

[gogins]

I think I can add Embeddable Common Lisp support to the Csound for Android app by repackaging the libraries in the CL REPL .apk, without need for changing my toolchain. At any rate, it's worth a try. That gets me to all of Silence except for WebAssembly support.

[gogins]

There is a new proposal for WebAssembly Interface Types that may provide a usable solution to the mapping problems. If this works out then in a year or three I can try porting everything to WebAssembly.

[gogins]

I am closing this issue so that I can redefine it in a more specific and less floundering way. This is primarily motivated by the evident facts that:

• Common Lisp on Android is not happening well enough to support everything that now goes into nudruz, and nudruz itself is working very well. I see no particular evidence that this lack of forward momentum in the Common Lisp world will change.
• Ditto for Common Lisp on WebAssembly.